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Sai che ora facciamo anche CORSI? Dai un'occhiata al 
calendario. 


Prefazione 


Erano anni che mi balenava in testa l’idea di un libro 
che si occupasse di questo argomento, che rielaborasse 
con approccio più maturo quanto da me scritto nelle mie 
primissime monografie e che raccogliesse alcuni dei 
miei interventi in quest'ambito tematico rimasti sparsi in 
articoli e blog post. 

Lo spunto per mettermi seriamente a lavorare al 
progetto mi è giunto nell'autunno 2019, in un periodo 
molto denso di attività formative rivolte in particolare a 
professionisti e piccoli imprenditori attivi nel settore 
dello sviluppo di tecnologia. Mi sono reso conto che 
sarebbe stato utile e prezioso poter segnalare ai miei 
corsisti un unico testo di riferimento strutturato, 
organico e il più possibile completo e che potesse 
rappresentare un riferimento divulgativo e nello stesso 
tempo solido da un punto di vista teorico anche per 
coloro che, pur non essendo professionisti del settore, 
vogliono avvicinarsi al tema. 

Visto l'argomento tecnico e rivolto al mondo delle 
piccole imprese e dei professionisti della tecnologia, si 
creava anche un'ottima occasione per poter finalmente 
sottoporre una mia pubblicazione agli amici di Apogeo 
Editore, con cui collaboro come autore del sito da molti 


anni e con cui proprio dall'autunno 2019 è iniziata una 
collaborazione anche in campo formativo. Dopo alcune 
telefonate per calibrare meglio il focus del libro, ho 
iniziato a lavorarci a inizio 2020; ricordo bene che i 
primi paragrafi uscirono dalla mia penna, o meglio dalla 
mia tastiera, durante la bizzarra settimana di Sanremo 
2020, quando, mentre tutti cercavamo di capire chi 
fosse quel cantante che a un certo punto era sparito dal 
palcoscenico, iniziava ad arrivare qualche notizia su uno 
strano virus che stava creando problemi in Cina. In 
quella settimana di metà febbraio ero fuori sede per 
motivi personali, e ricordo di essermi per la prima volta 
confrontato con il problema della pandemia quando il 17 
febbraio rientrai a Linate e dovetti fare la fila per uscire 
dal gate a causa di un controllo della temperatura 
corporea a tutti i viaggiatori. Pochi giorni dopo, mentre 
ero a Lodi per una tappa dai miei genitori, iniziai a 
sentire di alcuni amici residenti nei paesi attorno a 
Codogno che erano rimasti chiusi in quarantena. 
Preparai il mio trolley e rientrai nel mio appartamento 
pavese, pensando che il tutto si sarebbe comunque 
risolto nel giro di un paio di settimane. In quei giorni 
riuscii anche a fare la mia ultima trasferta di lavoro, in 
quel di Firenze, per la prima lezione del mio corso 
all’ISIA; e ricordo che fu la prima volta che percepii un 
senso di disagio e di velata paura per l'epidemia. In 
attesa del treno ad alta velocità, entrai nel market della 
stazione di Rogoredo a cercare un disinfettante per 
mani, che non si trovava, e ripiegai su una bottiglietta di 
disinfettante generico. Sul treno semideserto continuai a 


scrivere paragrafi del libro; consumai il pranzo in un 
ristorante vicino alla stazione di Santa Maria Novella, 
che esponeva un manifesto della campagna 
#Firenzenonsiferma. Feci la mia lezione e tornai a Lodi 
in giornata. Era il 4 marzo, e il giorno successivo, al 
ritorno nel mio appartamento di Pavia, iniziò l’escalation 
di notizie allarmanti e di conferenze stampa che 
comunicavano prescrizioni fuori da ogni immaginario e 
al di là di ogni fantasia distopica. 

Non fu facile entrare nell'ottica, soprattutto per uno 
come me abituato a considerare la casa solo come 
appoggio, ma nello stesso tempo a essere sempre in giro 
per l’Italia sia per il mio lavoro sia per questioni 
personali. Passate le prime due settimane di 
disorientamento, nelle quali devo ammettere fu davvero 
difficile trovare la concentrazione per scrivere, accettai 
questa nuova dimensione di working from home forzato 
e mi dedicai al libro con una certa costanza. Solo in un 
secondo momento, confrontandomi con altre persone 
che come me si erano trovate loro malgrado chiuse in 
casa da sole, mi resi conto di quanto fosse un privilegio 
poter avere un libro da scrivere, avere quindi qualcosa di 
stimolante cui pensare, che mi spingesse a studiare e 
fare letture che avevo troppe volte rimandato; 
semplicemente avere un obiettivo che mi permettesse di 
usare bene il tempo e di tenere occupata la mente su 
questioni interessanti e costruttive per il mio futuro 
lavorativo. 

Rovescio della medaglia fu che la pandemia fece 
slittare tutta una serie di iniziative culturali, 


accademiche, divulgative, tra cui anche quelle legate 
alla promozione e presentazione del nuovo libro, il 
quale, nei miei iniziali piani, doveva essere pubblicato 
prima dell'estate. A ciò aggiungiamo la sovrapposizione 
con un trasloco anch'esso slittato di qualche mese, ed 
eccoci che ci troviamo con il libro pubblicato in autunno. 

Devo dire comunque che, con il senno di poi, è stato 
meglio così. Questo ritardo forzato mi ha permesso di 
lavorare con meno pressione e lasciar sedimentare 
meglio le riflessioni e le letture fatte per redigere l’opera. 
Voglio quindi essere positivo e pensare che questi tre 
mesi non siano stati tempo perso ma che piuttosto 
abbiano avuto un effetto positivo anche sulla 
progettazione dell’opera e sulla qualità della scrittura. 
Ma questo sarete voi a dirmelo. 
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Introduzione 


La tutela e la governance 
delle creazioni tecnologiche: 
tra proprietà intellettuale e 

privacy 


Creazioni tecnologiche in che 


senso? 

Qualsiasi manuale di diritto della proprietà 
intellettuale apre la sua trattazione spiegandoci le radici 
storiche delle prime forme di tutela dei frutti della 
creatività umana. E visto che le prime leggi in materia 
risalgono al XVIII secolo è facile intuire che si riferissero 
solo alle forme più classiche della creatività: testi 
letterari, opere musicali, opere pittoriche e scultoree, 
opere teatrali, opere coreografiche. Nel secolo 
successivo, con l'evoluzione tecnologica, si arrivò poi ad 
ampliare il campo a nuove forme di creatività come la 
fotografia e la cinematografia. 

La nostra legge sul diritto d'autore, nel suo testo 
originario risalente al 1941, presentava all'articolo 2 un 


elenco di sette tipologie di opere dell'ingegno: le opere 
letterarie sia in forma scritta sia in forma orale, le opere 
e le composizioni musicali, le opere coreografiche e 
pantomimiche, le opere dell’arte figurativa in senso lato 
(pittura, scultura, disegno, scenografia), le opere 
architettoniche, le opere cinematografiche e le opere 
fotografiche. Questo elenco rimase invariato per mezzo 
secolo, fin quando negli anni Novanta la diffusione delle 
tecnologie informatiche portò all'aggiunta di due nuove 
tipologie di opere: il software (introdotto nel 1991) e le 
banche dati (introdotte nel 1996). 

NOTA 


A completare l'elenco sopraggiunse poi la decima tipologia, ossia le 
opere di design, per le quali però ci sarebbero da fare riflessioni molto 
diverse e abbastanza eccentriche rispetto agli scopi della nostra 
analisi. 

Queste due nuove forme di creatività avevano però 
caratteristiche peculiari che, da un lato, le rendevano 
per nulla assimilabili alle altre sette tipologie “classiche” 
per il processo creativo e per le dinamiche di 
acquisizione e gestione dei diritti e, dall'altro lato, 
necessitavano di un più ampio ripensamento dell'intero 
sistema del diritto d'autore a tal punto da richiedere 
l'introduzione di nuovi diritti e nuove tutele. 

Ai fini dell'analisi compiuta in queste pagine, 
parleremo di “creazioni tecnologiche” (0, come qualcuno 
più propriamente dice, “creazioni a contenuto 
tecnologico”; si veda in particolare Giorgio Floridia, “Le 
creazioni intellettuali a contenuto tecnologico”, in Paolo 
Auteri, Giorgio Floridia, Vito Maria Mangini e altri, Diritto 
industriale. Proprietà intellettuale e concorrenza, 


Giappichelli, Torino, 2005, cap. I, par. 5), mettendo il 
focus sulla loro caratteristica comune di essere legate in 
senso stretto allo sviluppo tecnologico: hanno una 
diretta applicazione in ambito tecnologico, la loro 
fruizione passa per la tecnologia, la loro utilità è 
dipendente dall'ambiente tecnologico in cui sono calate. 
Questo stretto legame con la tecnologia è innegabile, 
anche se, a ben vedere, sappiamo che il processo 
creativo del software a volte inizia disegnando un 
diagramma di flusso su un foglio di carta, e quindi ben 
prima di scrivere codici, e che le banche dati non sono 
necessariamente quelle fruibili in forma digitale ma 
continuano a esistere gli archivi, le biblioteche, i musei, i 
cataloghi che integrano appieno il concetto di banca 
dati analogica. 

Altra caratteristica distintiva di queste due nuove 
tipologie di creazione intellettuale è quella della 
funzionalità, cioè dell'essere più che altro destinate a 
svolgere funzioni e non tanto al semplice godimento 
intellettuale. 


NOTA 

Valeria Bellani e Laura Chimienti nel loro // diritto di autore nella prassi 
contrattuale. Dottrina, giurisprudenza e formulario (Giuffrè, Milano, 
2010, Il edizione) a p. 655 sottolineano che “il software è opera 
dell'ingegno appartenente al genus delle opere utilitaristiche e che 
per sua intrinseca natura è destinato a forme di fruizione non a sé 
stanti (come ad esempio il caso dell'ascolto di una composizione 
musicale, fine a se stessa), bensì dirette allo svolgimento di 
operazioni e attività. Considerato anche che il software, quale 
intelligenza artificiale, è fonte di un'energia immateriale, assimilabile 
a quella che viene messa a disposizione con le prestazioni di lavoro 
intellettuale [...], sembra opportuno tener conto di questa sua natura 
per operare una scelta fra le forme contrattuali [...]”. 


Se negli altri campi della creatività abbiamo dei 
lettori, degli ascoltatori, degli spettatori, qui abbiamo 
degli utilizzatori (o utenti), cioè soggetti che sono 
interessati a che l’opera non sia tanto piacevole e 
interessante quanto efficiente e adeguata all’uso per cui 
è stata creata. E questo risvolto cambia non poco la 
prospettiva anche sul piano giuridico e gestionale, come 
vedremo nel corso di tutto il libro. 


Tutela e governance in che senso? 

Questo libro vuole porre il focus sui temi della tutela e 
della governance. Tutelare è senza dubbio il principale 
obiettivo del cosiddetto diritto della proprietà 
intellettuale e l'approccio classico dei giuristi 
specializzati in questa materia è proprio quello di 
enfatizzare la portata delle forme di protezione offerte 
dalla legge. Tant'è che negli ultimi due decenni alcuni 
studiosi illuminati (fra tutti si leggano le prime 
monografie di Lawrence Lessig risalenti al periodo a 
cavallo tra la fine degli anni Novanta e l’inizio degli anni 
Duemila) hanno stigmatizzato e messo in guardia da 
una deriva in quella direzione che portasse a 
un'’ipertrofia della proprietà intellettuale. Ed è proprio in 
quelle che abbiamo chiamato creazioni tecnologiche che 
si è iniziato a percepire il problema di questa deriva 
iperprotezionistica, come spiegheremo in modo 
esauriente, della sovrapposizione tra diverse forme di 
tutela. L'approccio di questo libro, anche se entrerà nel 
dettaglio di tutti gli strumenti di tutela a disposizione 
dei titolari dei diritti, sarà comunque abbastanza 


neutrale e si offrirà debito spazio ed evidenza anche agli 
aspetti che interessano gli utilizzatori delle opere 
nonché a forme di gestione dei diritti sulle opere come 
open source e open data, che nel 2020 forse è ingenuo 
considerare “fenomeni nuovi” o “soluzioni alternative”. 
Come vedremo, il software open source e gli open data 
sono ormai protagonisti stabili e determinanti di questo 
scenario; e non a caso a questi temi sono dedicati interi 
capitoli del libro. 

Tuttavia, parlare solo di tutela può risultare limitante, 
poiché spesso coloro che producono, cedono, 
acquisiscono, gestiscono software e dati non sono 
interessati al mero aspetto delle tutele offerte 
dall'ordinamento su tali creazioni, ma vogliono 
conoscere anche gli strumenti messi a disposizione dalla 
prassi contrattuale e commerciale per avere il controllo e 
appunto la governance di tutte le fasi. Parlare anche di 
governance e non unicamente di tutela diventa 
fondamentale soprattutto nel campo dei dati, dove, 
come vedremo, non entra in gioco solo il livello della 
proprietà intellettuale, ma tende a sovrapporsi anche il 
livello della privacy, che aumenta le criticità e complica 
non poco il quadro. 


Premesse terminologiche 


Proprietà intellettuale 
L'espressione “proprietà intellettuale” è diventata 
molto utilizzata dagli anni Novanta in poi e indica una 


branca del diritto che in realtà raccoglie istituti giuridici 
molto differenti tra loro, come i brevetti per invenzione 
industriale, i marchi e gli altri segni distintivi, il diritto 
d'autore sulle opere creative, la tutela del design 
industriale, la tutela del segreto aziendale e del 
cosiddetto know-how, il diritto sui generis sulle banche 
dati (e, in parallelo, anche le norme in materia di 
concorrenza tra imprese). Per ciascuna di queste 
manifestazioni dell’inventiva e della creatività umana, 
l'ordinamento giuridico riconosce ai titolari una serie di 
diritti esclusivi, grazie ai quali essi stessi o i loro aventi 
causa possono remunerarsi per mezzo della cessione di 
tali diritti o la concessione di licenze basate su tali 
diritti. 

L'espressione “proprietà intellettuale” si basa su una 
similitudine, in verità un po’ forzata, tra il concetto di 
proprietà inteso in senso classico (cioè la proprietà sui 
beni materiali mobili e immobili come la conosciamo già 
dai tempi del diritto romano) e il concetto di proprietà su 
questi nuovi beni che però sono immateriali e nello 
stesso tempo sono diventati assets fondamentali nei 
mercati di oggi. 

In alcuni casi si trova l’espressione “proprietà 
industriale” con un significato quasi equivalente, ma 
che pone l'accento più sull'aspetto appunto industriale 
(quindi brevetti, marchi, design, segreto) e meno 
sull'aspetto delle creazioni intellettuali (letteratura, 
fotografia, musica, cinematografia, banche dati). 


NOTA 
Come vedremo, infatti, in Italia abbiamo un testo unico delle norme 
su questa materia che si chiama Codice della proprietà industriale e 


che appunto non contiene le norme in materia di diritto d'autore 
sulle opere creative.. 


Diritto d’autore e copyright 

Una delle branche principali della cosiddetta proprietà 
intellettuale è il diritto d'autore, anche chiamato con la 
dizione anglosassone “copyright”. Bisogna comunque 
tenere presente che dire “copyright” o dire “diritto 
d'autore” non è proprio la stessa cosa. Per semplificare si 
usano di solito le due espressioni come rispettive 
traduzioni, ma in realtà esse fanno riferimento a due 
istituti giuridici differenti. Il copyright ha origine 
all’inizio del XVIII secolo ed è figlio della Rivoluzione 
industriale inglese; dall'ordinamento giuridico inglese il 
modello è stato poi esportato negli Stati Uniti e in altre 
ex colonie inglesi. 

Il concetto di diritto d'autore è invece figlio della 
Rivoluzione francese e ha la sua prima formalizzazione 
all’interno delle leggi repubblicane approvate alla fine 
dello stesso secolo. Dalla Francia, anche grazie al 
periodo di dominazione napoleonica, il modello è stato 
esportato in buona parte dei Paesi dell'Europa 
continentale, tra cui l’Italia, la Spagna, la Germania. 
Negli ultimi decenni una serie di convenzioni 
internazionali ha cercato di avvicinare sempre più i due 
modelli, in virtù anche di una globalizzazione del 
mercato delle produzioni intellettuali. 

Per praticità, in questo libro in linea di massima i due 
termini verranno utilizzati come sinonimi. 


Privacy e data protection 

Anche i concetti di privacy e di data protection 
vengono spesso utilizzati in modo improprio come 
sinonimi. In realtà, come si può intuire, il concetto di 
privacy è più ampio e comprende tutta una serie di 
diritti della persona che riguardano la sua riservatezza e 
di strumenti che un individuo può mettere in campo per 
evitare invasioni indebite nella sua sfera privata. La data 
protection riguarda invece in senso più stretto l'aspetto 
della protezione dei dati personali, secondo la 
definizione vigente e in genere accreditata di “dato 
personale” che forniremo e commenteremo nell'ultimo 
capitolo del libro. 


LDA, GDPR e altre fonti normative 
Trattandosi di un libro di stampo per lo più giuridico, 
troveremo spesso nel corso della trattazione riferimenti 
a testi normativi di varia natura: direttive europee, leggi 

ordinarie dello Stato, decreti, regolamenti. Ciascuna 
fonte verrà di volta in volta introdotta e illustrata. A ogni 
modo, le due principali fonti di riferimento per un libro 
come questo (che appunto si occupa di diritto d'autore e 
privacy) saranno citate in forma di acronimo. Dunque, 
quando troveremo l’acronimo LDA vorrà dire che stiamo 
facendo riferimento alla Legge sul Diritto d'Autore, più 
propriamente la Legge 22 aprile 1941, n. 633 
“Protezione del diritto d'autore e di altri diritti connessi 
al suo esercizio”; mentre quando troveremo l'acronimo 
GDPR il riferimento sarà al Regolamento Generale sulla 


Protezione dei Dati (benché l'acronimo derivi dalla 
dizione inglese General Data Protection Regulation), più 
propriamente Regolamento (UE) n. 2016/679 del 
Parlamento Europeo e del Consiglio del 27 aprile 2016 
relativo alla protezione delle persone fisiche con 
riguardo al trattamento dei dati personali, nonché alla 
libera circolazione di tali dati e che abroga la direttiva n. 
95/46/CE. 


Capitolo 1 


Il diritto d’autore sulle 
creazioni tecnologiche: 
primi passi 


Il campo d’azione del diritto 
d’autore 


Avere ben chiaro di che cosa si occupa il diritto 
d'autore, in quale campo agisce, è fondamentale per 
evitare di cadere in facili equivoci e, per esempio, 
confondere l'ambito del diritto d'autore con quello dei 
brevetti per invenzione o con quello dei marchi e degli 
altri segni distintivi. Il campo d'azione del diritto 
d'autore viene ben definito dai primi due articoli della 
Legge n. 633/1941 (LDA). 


Sono protette ai sensi di questa legge le opere dell'ingegno di 
carattere creativo che appartengono alla letteratura, alla musica, alle 
arti figurative, all'architettura, al teatro ed alla cinematografia, 
qualunque ne sia il modo o la forma di espressione. 


Sono altresì protetti i programmi per elaboratore come opere 
letterarie [...], nonché le banche di dati che per la scelta o la 
disposizione del materiale costituiscono una creazione intellettuale 
dell'autore. 


Il primo paragrafo della norma, che già copre buona 
parte delle forme della creatività umana, risale al testo 


originario ed è uguale a se stesso dal 1941. Il secondo 
paragrafo (che qui è presentato in versione abbreviata) 
è stato invece aggiunto in un secondo momento, come 
d'altronde si può intuire dato che si occupa di due forme 
di creazioni più recenti (software e banche dati). 

L'articolo 2 non fa altro che definire in modo più 
dettagliato il campo d'azione del diritto d'autore 
individuando dieci categorie di opere dell'ingegno 
tutelate dalla legge italiana: in questo elenco il software 
rappresenta il numero 8 e le banche dati rappresentano 
il numero 9; e queste due saranno le tipologie di opere 
che tratteremo in questo libro. 

Bisogna inoltre precisare che il copyright non si 
occupa di tutelare le idee in sé o le semplici 
informazioni, ma solo le opere dell'ingegno, cioè la 
forma espressiva in cui un’idea creativa viene 
estrinsecata. Si tratta di un principio cardine di tutto il 
diritto d’autore e cristallizzato nell'articolo 9, comma 2 
dei TRIPS, che recita: 


La protezione del diritto d'autore copre le espressioni e non le idee, i 
procedimenti, i metodi di funzionamento o i concetti matematici in 
quanto tali. 

Principio che poi sarà ribadito anche dalle norme in 
materia di tutela del software, che appunto escludono 
dalla copertura le idee e i principi che stanno alla base 
di un programma per elaboratore. 


Il diritto d’autore: una tutela 
automatica, duratura e 


gratuita 


Se l’unico requisito richiesto dalla legge è la presenza 
del carattere creativo, qualsiasi opera che rientri nelle 
tipologie descritte dagli articoli 1 e 2 LDA e che presenti 
quel minimo di originalità e novità risulta di per sé 
coperta da tutti i diritti d'autore previsti dalla legge. 

Con un'espressione forse semplicistica ma senza 
dubbio efficace, si usa dire che il diritto d'autore sulle 
proprie creazioni si acquisisce in automatico con la 
creazione. Ciò è chiarito in modo laconico dall'articolo 6 
LDA: 


Il titolo originario dell'acquisto del diritto di autore è costituito dalla 
creazione dell'opera, quale particolare espressione del lavoro 
intellettuale. 

Questo è uno degli aspetti su cui circolano spesso 
equivoci. Molti infatti pensano, sbagliando, che il diritto 
d'autore su una propria opera creativa si acquisisca 
attraverso la registrazione dell’opera presso un pubblico 
ufficio, come avviene per i marchi e per le invenzioni 
brevettabili. In realtà, l’autore acquisisce i diritti di 
tutela sulla propria opera con la semplice creazione 
dell’opera stessa, a condizione che questa rientri nelle 
tipologie di opere contemplate dalla legge sul diritto 
d'autore (si vedano gli articoli 1 e 2 della Legge n. 
633/1941) e presenti il requisito essenziale del carattere 
creativo (cioè il fatto che l’opera sia sufficientemente 
nuova e originale e non la semplice riproduzione di 
qualcosa già creato da altri o una mera elencazione di 
dati). 


Da questo principio deriva una regola aurea per coloro 
che vogliono utilizzare opere creative esistenti, che 
potremmo enunciare così: se l'opera non l'ho creata io, 
allora l'avrà creata qualcun altro e, quindi, questo 
qualcun altro deterrà i diritti d'autore su di essa. AI di là 
del fatto che ci sia una nota sul copyright, un avviso di 
“diritti riservati”, dunque, devo astenermi da 
qualsivoglia utilizzo e devo chiedere uno specifico 
permesso al titolare, a meno che io sia sicuro che questi 
diritti siano scaduti, che si tratti di un caso di “libera 
utilizzazione” consentito espressamente dalla legge (ne 
parleremo più avanti) o che l'opera sia rilasciata con una 
licenza di libero utilizzo. 

Lo schema della Figura 1.1 rappresenta bene questo 
concetto: da un lato la regola generale della “tutela by 
default”, dall'altro le eccezioni a questa regola 
rappresentate o dalle cosiddette libere utilizzazioni o 
dalle licenze open. 


regola eccezione 


copyright libero utilizzo 


(C) stabilito stabilito 
dal titolare 


dalla legge 
| 99 dei diritti 


> vedi articoli 65 
scadenza fl?” e seguenti 
termini A * Legge 633/1941 


pubblico dominio 








Figura 1.1 Uno schema molto efficace che nella parte sinistra mostra la 
regola generale, cioè la “tutela by default” del copyright che viene meno 
solo con la scadenza di tutti i diritti e il conseguente passaggio dell’opera 
in pubblico dominio; nella parte destra mostra invece le due principali 
eccezioni a questa regola, cioè le cosiddette “libere utilizzazioni” previste 
dalla legge e il libero utilizzo stabilito dal titolare dei diritti attraverso 
l'applicazione all'opera di una licenza open. 


Tra diritto civile e diritto 
penale 


Il diritto d'autore è una branca del diritto commerciale 
che a sua volta è una branca del diritto civile. L'impianto 
normativo è di chiara matrice civilistica, dato che ha lo 
scopo di porre una serie di diritti soggettivi a favore 
degli autori e di individuare le relative azioni esperibili 
per la tutela di tali diritti. 

La norma di riferimento è l'articolo 158 LDA, il cui 
comma 1 recita: 

Chi venga leso nell'esercizio di un diritto di utilizzazione economica a 

lui spettante può agire in giudizio per ottenere, oltre al risarcimento 

del danno, che, a spese dell'autore della violazione, sia distrutto o 

rimosso lo stato di fatto da cui risulta la violazione. 

Il successivo comma 2 della norma rimanda invece ai 
principi generali del Codice Civile in materia di 
liquidazione del danno civile (articoli 1223, 1226 e 1227 
Codice Civile) e di ristoro del lucro cessante (articolo 
2056, comma 2, Codice Civile), anche tenuto conto degli 
utili realizzati in violazione del diritto. Il giudice può 
altresì liquidare il danno in via forfettaria sulla base 
quantomeno dell’importo dei diritti che avrebbero 
dovuto essere riconosciuti, qualora l’autore della 


violazione avesse chiesto al titolare l'autorizzazione per 
l'utilizzazione del diritto. Infine il comma 3 ricorda che, 
in caso di violazione di diritti d'autore, sono dovuti 
anche i danni non patrimoniali. 

Buona parte dell'attività di un avvocato che si occupa 
di diritto d'autore è di matrice civilista: ha infatti a che 
fare soprattutto con la preparazione e verifica di 
contratti, licenze, liberatorie, termini d'uso e con il 
valutare la tutelabilità delle creazioni del cliente. Inoltre 
le eventuali diatribe legali nate per la violazione di 
diritti d'autore portano a cause civili che, secondo 
l'attuale ripartizione delle competenze giurisdizionali, 
devono essere necessariamente instaurate di fronte al 
Tribunale delle imprese, che è appunto una sezione 
specializzata presso i tribunali civili dei capoluoghi di 
regione (eccetto la Valle d'Aosta). 

Ciò non toglie che l'ordinamento giuridico abbia 
ritenuto opportuno tutelare alcuni aspetti del diritto 
d'autore attraverso norme penali, le quali offrono una 
tutela aggiuntiva e parallela che entra in gioco nei casi 
più gravi, cioè quando si riscontra il compimento di uno 
dei reati definiti dalla legge. 

I reati nel campo del diritto d'autore sono 
regolamentati nella Sezione Il del Capo III LDA, intitolata 
appunto “Difese e sanzioni penali”. Tale sezione, nella 
sua versione originaria (risalente quindi ancora al 1941) 
prevedeva solo le fattispecie di reato descritte 
nell'articolo 171; negli anni il legislatore ha aggiunto 
alla sezione diverse norme che prevedono altri reati, tra 


cui alcuni riguardano anche il campo del software e 
delle banche dati. 

In alcuni casi, che però non riguardano direttamente 
l'ambito del software e delle banche dati, è prevista 
anche una tutela di carattere amministrativo che affida a 
enti come SIAE e AGCOM il compito di vigilare 
sull'utilizzo delle opere, raccogliere le relative 
segnalazioni e comminare le sanzioni (sanzioni 
amministrative, appunto). 


I diritti di utilizzazione 
economica 


Per tradizione si usa distinguere i diritti d'autore in 
due macrocategorie: i diritti di tipo personale e i diritti di 
tipo patrimoniale. Come spiegheremo meglio nel 
paragrafo successivo, nella tutela delle creazioni 
tecnologiche sono i secondi a ricoprire un ruolo più 
centrale. E come rappresentato nella Figura 1.2 essi 
sono suddivisi in diritti esclusivi di utilizzazione 
economica, diritti connessi e diritto sui generis del 
costitutore di banche dati. 


Diritti previsti dalla Legge 633/1941 


pei 


diritti di tipo personale diritti di tipo patrimoniale 


diritti morali d'autore diritti esclusivi diritto sui 
diritti inalienabili di utilizzazione generis 
e inestinguibili, economica sera . particolare diritto 
strettamente legati diritti alienabili, diritti CONNESSI gel costitutore di 
alla personalità e alla scomponibili e diritti esclusivi SU —banche dati che 
reputazione dell’autore indipendenti attività simili 0 
l'uno dall'altro; connesse a quelle 
durano 70 anni dalla tutelate dai diritti 
morte dell'autore di utilizzazione 
economica 


hanno richiesto 
un rilevante 
investimento 








Figura 1.2 La classificazione dei diritti previsti dalla Legge n. 633/1941. 


| diritti esclusivi di utilizzazione economica sono i 
diritti che permettono agli autori di remunerarsi grazie 
alla loro creatività; rappresentano una sorta di “diritto 
del lavoro” per coloro che di professione fanno gli autori 
di opere e infatti sono i diritti che di solito diventano 
oggetto delle attività di gestione, cessione, 
contrattazione, licenziamento. Sono quindi i diritti che, 
ai fini della nostra esposizione, risultano più centrali; del 
diritto sui generis parleremo più in dettaglio in apposito 
capitolo; non ci occuperemo invece né dei diritti 
connessi (che riguardano più che altro il mondo delle 
produzioni discografiche, cinematografiche, 
radiotelevisive) né dei diritti all’equo compenso (che 
rappresentano un capitolo a sé). 

| diritti di utilizzazione economica sono per definizione 
alienabili, ossia hanno la principale funzione di essere 
ceduti in cambio di una remunerazione monetaria o di 


altra contropartita economica. E sono anche 
scomponibili e indipendenti tra loro: ciò significa che è 
possibile cederli tutti “in blocco”, oppure cederne solo 
alcuni, o addirittura, nel cederli, tagliarli in “fette” più 
piccole. 

Questi diritti sono inoltre “diritti esclusivi”. Per 
spiegare il concetto di “diritto esclusivo” si cita spesso 
l’espressione latina “ius excludendi alios", cioè il diritto 
di escludere gli altri da una determinata sfera d'azione, 
e dunque la possibilità da parte del titolare di tali diritti 
di vietare condotte da lui non autorizzate. 

Secondo la classificazione utilizzata dalla legge 
italiana negli articoli da 12 a 18-bis, i diritti esclusivi di 
utilizzazione economica riservati all'autore di un’opera 
dell'ingegno sono: 


e il diritto di pubblicare l’opera (art. 12); 

e il diritto di riprodurre l’opera (art. 13); 

* il diritto di trascrivere l’opera (art. 14); 

e il diritto di eseguire, rappresentare o recitare in 
pubblico l’opera (art. 15); 

e il diritto di comunicare al pubblico l’opera e di 
mettere l’opera a disposizione del pubblico (art. 16); 

e il diritto di distribuire l’opera (art. 17); 

* il diritto di tradurre l’opera (art. 18); 

e il diritto di elaborare l’opera (art. 18); 

e il diritto di pubblicare le opere in raccolta (art. 18); 

e il diritto di autorizzare il prestito o il noleggio 
dell’opera (art. 18-bis). 


Questi diritti hanno una scadenza temporale che, in 
buona parte dei Paesi che hanno aderito alla 


Convenzione di Berna, è di settant'anni dalla morte 
dell'autore. Significa che essi durano per tutta la vita di 
un autore e, dopo la sua morte, durano altri settant'anni 
solari interi. Se pensiamo a un’opera scritta da un 
giovane autore ventenne e ipotizzando un'aspettativa di 
vita di novant'anni di età, l'opera sarà tutelata per un 
totale di centoquarant'anni, cioè settant'anni durante la 
vita dell'autore e altri settanta dopo la sua morte. Una 
durata senza dubbio molto lunga, probabilmente 
insensata per moltissime opere concepite fin dall'inizio 
per avere un orizzonte temporale limitato (pensiamo ai 
classici tormentoni musicali estivi) e ancora più 
insensata nel campo delle creazioni tecnologiche, che 
per loro natura sono soggette a una rapida 
obsolescenza. Chi mai oggi nel 2020 utilizzerebbe e 
comprerebbe la licenza di un’applicazione scritta nei 
primi anni Ottanta per un Commodore 64? Eppure, da 
un punto di vista tecnico, il codice di quell’applicazione 
è tutelato per tutta la vita del suo sviluppatore e per 
ulteriori settant'anni. 


Esistono i diritti morali sulle 
creazioni tecnologiche? 


La già menzionata distinzione fra diritti di tipo 
personale (anche detti diritti morali d'autore) e diritti di 
tipo patrimoniale è caratteristica degli ordinamenti figli 
del modello francese, come appunto l'ordinamento 
italiano; non è però presente negli ordinamenti figli del 
modello anglosassone, che invece non a caso parlano di 


copyright, cioè diritto di fare copie, e lo considerano un 
istituto giuridico con vocazione perlopiù commerciale. 

| diritti morali sono diritti legati in senso stretto alla 
sfera personale dell’autore, alla sua reputazione 
creativa; i principali sono il diritto a veder riconosciuto il 
proprio ruolo di autore (diritto al riconoscimento della 
paternità) e il diritto a opporsi a modifiche, mutilazioni, 
distorsioni dell’opera che risultino lesive della propria 
reputazione di autore. 

Essi sono inalienabili e inestinguibili; queste due 
caratteristiche hanno un impatto molto forte sulle 
modalità con cui poi possono essere gestiti e trasferiti i 
diritti sulle opere. “Inalienabili” significa che non 
possono mai essere ceduti, dunque l’autore anche 
volendo non può spogliarsene; e per converso dobbiamo 
tenere presente che, anche facendosi cedere tutta la 
gamma dei diritti di utilizzazione, in realtà l’autore non 
ce lo potremo “togliere di torno” in modo radicale e 
definitivo, poiché lui in determinate situazioni, che 
appunto toccano la sua sfera “morale”, potrà sempre 
esercitare quei diritti. 

Non solo; i diritti morali sono pure inestinguibili. 
Significa che non hanno una scadenza e che alla morte 
dell'autore vengono esercitati dagli eredi, anche oltre il 
limite dei settant'anni. 

Senza dubbio l'impostazione angloamericana risulta 
più funzionale e meno complicata dal punto di vista 
giuridico, visto che gli autori possono con più facilità 
essere “liquidati” attraverso un compenso economico e i 
diritti possono essere gestiti dai loro aventi causa 


(editori, produttori, software house ecc.) senza 
particolari preoccupazioni. 

Questa discrasia tra i due “fronti” (quello 
angloamericano senza diritti morali e quello dei Paesi 
europei con diritti morali) crea non pochi problemi nella 
gestione e nella governance delle creazioni 
tecnologiche; infatti la prassi contrattuale legata alla 
produzione e diffusione di software e banche dati è nata 
quasi interamente negli Stati Uniti (appunto un Paese in 
cui non esistono i diritti morali d'autore) ed è stata poi 
esportata negli altri ordinamenti e adattata a quei 
diversi contesti giuridici ed economici. 

La questione centrale però è: esistono davvero i diritti 
morali su software e banche dati? Secondo un 
orientamento dottrinale (cui anche chi scrive sente di 
aderire) le creazioni tecnologiche, proprio in virtù della 
loro vocazione “utilitaristica”, non sarebbero adatte a 
rispecchiare la personalità creativa dell'autore, il suo 
stile, il SUO Modo di vedere, come invece succede con le 
opere dell'ingegno più classiche (letteratura, arte 
figurativa, musica, teatro, cinema). Nello sviluppo di 
software spesso la buona prassi spinge a favore del 
raggiungimento della migliore funzionalità, organicità, 
velocità, coerenza tecnica, solidità dell’opera, lasciando 
poco spazio alla creatività in senso pieno. Si aggiunga 
che alcune norme di legge rendono comunque possibile 
la modifica e l'adattamento del codice quando è reso 
necessario da esigenze di interoperabilità. Inoltre, nel 
caso di banche dati prive di carattere creativo e perciò 
tutelate solo con il diritto sui generis ma non con un 


pieno diritto d’autore, l'applicazione dei diritti morali è 
espressamente esclusa. 

In sostanza, quindi, l'ordinamento tende a lasciare in 
secondo piano i diritti morali sulle creazioni 
tecnologiche e a riconoscere agli autori al massimo un 
diritto a essere riconosciuti e menzionati, escludendo 
invece un diritto morale a impedire modifiche che siano 
lesive della reputazione creativa dell’autore. 


Opere derivate ed 
elaborazioni creative 


Quando si crea un’opera autonoma e nuova partendo 
però da un’opera preesistente si usa parlare di “opera 
derivata” utilizzando un termine di importazione 
angloamericana (derivative work). Classici esempi sono 
la traduzione di un libro in un’altra lingua, il remix di un 
brano musicale, la trasposizione cinematografica di un 
romanzo, ma anche l'adattamento a MacOS di un 
software nato per Windows. 

La definizione dettata dallo United States Copyright 
Act (17 U.S.C. $ 101) è la seguente: 


A “derivative work” is a work based upon one or more preexisting 
works, such as a translation, musical arrangement, dramatization, 
fictionalization, motion picture version, sound recording, art 
reproduction, abridgment, condensation, or any other form in which 
a work may be recast, transformed, or adapted. A work consisting of 
editorial revisions, annotations, elaborations, or other modifications 
which, as a whole, represent an original work of authorship, is a 
“derivative work”. 


[Una “opera derivata” è un’opera basata su una o più opere 
preesistenti, come una traduzione, un arrangiamento musicale, una 


trasformazione in sceneggiatura o in opera narrativa, una versione 

cinematografica, una registrazione in versione sonora, una 

rielaborazione artistica, un riassunto o una sinossi o qualsiasi altra 
forma in cui un’opera può essere rielaborata, trasformata o adattata. 

Un'opera composta da revisioni editoriali, annotazioni, elaborazioni o 

altre modifiche che, nel loro insieme, rappresentano un intervento 

creativo originale, è una “opera derivata”.] 

Nel contesto italiano si utilizza in modo più corretto 
l'espressione “elaborazione di carattere creativo” 
contenuta nell'articolo 4 LDA, norma che riprende in 
sostanza il testo dell'articolo 2.3 della Convenzione di 
Berna: 


Si proteggono come opere originali, senza pregiudizio dei diritti 

dell'autore dell'opera originale, le traduzioni, gli adattamenti, le 

riduzioni musicali e le altre trasformazioni di un’opera letteraria o 

artistica. 

Significa quindi che colui che realizza un’opera 
derivata diventa a tutti gli effetti autore di un’opera 
nuova, con autonomi diritti; ma, nello stesso tempo, 
l'autore dell’opera originaria diventa in un certo senso 
“coautore” dell’opera derivata. Inoltre, essendo 
l'elaborazione creativa un'attività coperta da uno 
specifico diritto esclusivo (articolo 18 LDA), è necessario 
che l’autore dell’opera originaria abbia dato il suo 
espresso e preventivo consenso alla realizzazione 
dell’opera derivata. 

Vedremo nei capitoli che seguono quanto sia centrale 
il concetto di derivazione e quanto sia determinante la 
possibilità di fare opere derivate nel campo delle 
creazioni tecnologiche; ma soprattutto ne vedremo in 
modo particolare le implicazioni giuridiche. 


Quali vie per cedere e 
acquisire creazioni 
tecnologiche? 


I modelli di business per sfruttare da un punto di vista 
economico le creazioni tecnologiche e con loro i modelli 
contrattuali per cedere e acquisire i diritti su di esse 
sono molto variegati; tuttavia possiamo ricondurli a tre 
principali vie: quella della cessione dei diritti (per lo più 
in via esclusiva), quella della licenza d'uso e quella 
dell'accesso online. 


Cessione dei diritti (esclusiva o 


non esclusiva) 

Attraverso un contratto di cessione dei diritti, la 
titolarità dei diritti sull'opera viene trasferita da un 
soggetto (cedente) a un altro soggetto (cessionario). 

Il caso più frequente è quello della cessione in via 
esclusiva di tutto il fascio dei diritti d'autore; con essa il 
cedente si spoglia per intero dei suoi diritti e il 
cessionario diventa a tutti gli effetti il nuovo titolare. Dal 
momento della cessione e per tutta la durata del 
contratto, quindi, il cedente (anche se è l’autore 
originario dell’opera) perde la possibilità di controllarne 
gli utilizzi e di sfruttarli da un punto di vista economico. 

La cessione può anche essere in via non esclusiva e 
può inoltre riguardare solo alcuni dei diritti d'autore. In 
quel caso, a seconda di come verrà strutturato il 
contratto di cessione, per tutta la sua durata si creerà 


una situazione di contitolarità dei diritti, cioè cedente e 
cessionario vanteranno alcuni diritti 
contemporaneamente sulla stessa opera e ciascuno dei 
due potrà controllarne e sfruttarne alcuni utilizzi. 

La parte della legge italiana sul diritto d'autore 
dedicata ai contratti di cessione dei diritti è quella 
compresa tra l'articolo 118 e l’articolo 141; tuttavia 
queste norme trattano solo il contratto di edizione a 
stampa (che di norma riguarda l'ambito delle edizioni 
letterarie, grafico-figurative, musicali) e il contratto di 
rappresentazione ed esecuzione (che di solito riguarda 
l'ambito del teatro e della musica dal vivo). Non 
disponiamo quindi nel nostro ordinamento di norme 
specifiche per la cessione dei diritti d'autore nel settore 
dell'informatica e della produzione di banche dati; ciò 
comunque non toglie che la giurisprudenza e la dottrina 
giuridica italiane abbiano negli anni individuato una 
solida prassi contrattuale cui poter fare riferimento. 
Come è intuibile, i modelli contrattuali in questo settore 
sono più che altro di matrice angloamericana; è dagli 
Stati Uniti, infatti, che negli anni Ottanta sono stati 
importati in Italia i primi modelli di contratti ed è su quei 
modelli che è iniziata l’attività di inquadramento e 
adattamento nel contesto giuridico nazionale. 


Licenza d’uso 
Per capire bene che cos'è una licenza, partiamo 
dall'analisi etimologica del termine: la parola “licenza” 
deriva dal latino /icére, che significa “permettere”, e 


indica in linea generica un atto autorizzativo, 
un'autorizzazione. 

Il titolare dei diritti (licenziante) concede 
all'utilizzatore (licenziatario) di poter fare alcuni utilizzi 
dell’opera, a patto che quest'ultimo rispetti determinate 
condizioni. La licenza d'uso rappresenta quindi un 
permesso condizionato, una sorta di “puoi fare X a 
condizione che tu faccia Y”. Nei miei corsi di formazione 
sono solito spiegare che le licenze hanno sempre “due 
anime”: una parte in cui vengono indicati gli utilizzi 
concessi e un’altra parte in cui vengono indicate le 
condizioni che l'utilizzatore deve rispettare. 

Dal punto di vista della teoria giuridica italiana, la 
licenza d'uso di opere dell'ingegno è un contratto 
atipico (cioè non disciplinato da specifiche norme 
giuridiche, in gergo “non tipizzato”) e viene per 
tradizione associata al contratto di locazione. 
Rimanendo proprio su questa metafora, possiamo 
pensare all'opera dell'ingegno come a un appartamento 
che viene messo in locazione (0, come si usa dire in 
modo improprio, “in affitto”). Nella metafora, il 
proprietario dell’appartamento è il titolare dei diritti 
sull'opera (che a seconda dei casi può essere una casa 
editrice, una casa discografica, una software house, o 
anche l’autore stesso); l'inquilino è invece l'utilizzatore 
e licenziatario dell'opera; il contratto di locazione è 
appunto la licenza d'uso. 

Avremo modo di mettere bene a fuoco tutte le varie 
tipologie di licenze nel campo del software e delle 
banche dati. Possiamo però fin da subito illustrare una 


prima suddivisione in due macrocategorie. Da un lato, 
abbiamo le licenze rivolte a un licenziatario definito: in 
questo caso il licenziante Tizio offre l’opera in licenza al 
licenziatario Caio. Si tratta quindi di un contratto 
sottoscritto da due soggetti e strutturato per 
regolamentare il loro specifico rapporto. Pensiamo al 
caso di uno studio legale che necessita di una banca 
dati con leggi e sentenze. Lo studio contatterà la casa 
editrice che realizza questa banca dati e chiederà una 
licenza d'uso per l'utilizzo dell’opera. La casa editrice 
tenderà a proporre un contratto di licenza ad hoc per le 
esigenze dello studio, che terrà conto di vari fattori, 
come il numero di professionisti che lavorano nello 
studio, la durata temporale della licenza, i tipi di 
contenuti compresi nella banca dati (solo le leggi, solo le 
sentenze, entrambe ecc.). È dunque questo il caso più 
aderente alla metafora del contratto di locazione di un 
appartamento appena menzionata. 

Dall'altro lato, ci sono le licenze in cui solo il 
licenziante è un soggetto determinato, mentre il 
licenziatario è indefinito; diventa licenziatario qualsiasi 
utilizzatore che decida di utilizzare l’opera sulla base 
delle autorizzazioni e delle condizioni indicate nella 
licenza. Si tratta quindi di licenze pubbliche e 
standardizzate. Poniamo il caso dell'acquisto di un 
computer, di quelli con sistema operativo integrato; una 
volta acquistato il dispositivo, al primo avvio, 
all'acquirente comparirà una licenza standard, uguale 
per qualsiasi utente; l'acquirente potrà solo accettarla 
così com'è, oppure anche rifiutarla (ma in tal caso 


sarebbe tenuto a non utilizzare quella copia del sistema 
operativo). Come altro esempio, pensiamo al caso delle 
licenze open, cioè le licenze per software open source e 
le licenze per contenuti aperti (Creative Commons e 
simili), che, pur avendo una manciata di varianti, 
rappresentano dei documenti standard e noti in tutto il 
mondo. 

Le licenze che appartengono a questa seconda 
tipologia (cosiddette “licenze open”) hanno 
caratteristiche comuni con i cosiddetti contratti per 
adesione e l'accettazione da parte 
dell’utilizzatore/licenziatario avviene per 
comportamento concludente, ossia il semplice fatto che 
egli utilizzi l’opera implica che egli la utilizzi nel rispetto 
delle condizioni imposte dalla licenza. Il mancato 
rispetto di tali condizioni fa venir meno in modo 
automatico i permessi concessi dalla licenza. 

Sempre sfruttando il linguaggio metaforico, possiamo 
distinguere le licenze anche sulla base del loro livello di 
“apertura” (openness, in inglese). Una licenza open è 
una licenza in cui le libertà concesse agli utenti 
prevalgono sia a livello di quantità sia a livello di portata 
sulle condizioni imposte. In un certo senso, il titolare dei 
diritti applica una licenza open alle proprie opere per 
riaprire ciò che il principio “closed by default” del 
copyright ha tenuto chiuso. Al contrario, una licenza 
proprietaria è una licenza in cui le condizioni imposte 
prevalgono sulle autorizzazioni concesse agli 
utilizzatori. Con l'applicazione di queste licenze il 
titolare dei diritti non fa altro che sottolineare e 


rafforzare ancora di più le limitazioni imposte dal diritto 
d'autore e in alcuni casi ad aggiungerne di nuove e di 
più specifiche (Figura 1.3). 
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Figura 1.3 La differenza tra licenza proprietaria e licenza open spiegata 
con la chiara metafora del cartello posto all'ingresso di un parco. 


Accesso online 

C'è poi una terza via che sfrutta la ormai capillare 
diffusione della banda larga e che prevede la fruizione 
dell’opera online. Da un punto di vista tecnico l’opera 
risiede su un webserver e l'utente ne fruisce 
connettendosi a una specifica piattaforma web. Questa 
modalità può riguardare qualsivoglia tipologia di opere 
ed è quella cui siamo ormai più abituati: i video su 
YouTube, la musica su Spotify; e come vedremo meglio 


riguarda anche la fruizione di opere come banche dati e 
software (si pensi per esempio a Google Docs oppure a 
Office 365). 

Da un punto di vista giuridico, questa via comporta 
sostanziali differenze rispetto alla cessione dei diritti e 
alla licenza d'uso. A ben vedere usciamo anche dal 
campo d'azione del copyright vero e proprio, inteso in 
senso etimologico di “diritto di copia”, dato che non 
avviene nemmeno un vero e proprio trasferimento di 
una copia dell’opera; in alcuni casi si tratta più che altro 
di una copia temporanea che poi non viene salvata sul 
dispositivo dell'utente. Tra i vari diritti di utilizzazione 
che abbiamo già elencato nel paragrafo “I diritti di 
utilizzazione economica”, diventa qui centrale il diritto 
di cui all'articolo 16 LDA, cioè il diritto esclusivo di 
mettere l’opera a disposizione del pubblico in maniera 
che ciascuno possa avervi accesso dal luogo e nel 
momento scelti individualmente, dunque un diritto che 
tutela proprio gli utilizzi di opere creative attraverso 
Internet. 

Anche i modelli contrattuali qui diventano altri; ci 
allontaniamo dai modelli della cessione, della 
compravendita, della locazione e ci avviciniamo più ai 
contratti di fornitura di servizi. Infatti, per fruire delle 
opere secondo la via dell'accesso online, agli utenti è 
richiesto di solito di registrarsi su apposita piattaforma 
web e di sottoscrivere i cosiddetti “termini d'uso” 0 
“termini di servizio”: in sostanza si tratta di un vero e 
proprio contratto tra il service provider e l'utente che 


regolamenta l'accesso alla piattaforma e alle opere in 
essa contenute. 

Dal momento che l'accesso all'opera e al servizio 
connesso avviene attraverso Internet, cioè attraverso un 
mezzo che per sua natura travalica i confini nazionali, si 
pone un inevitabile problema di legge applicabile e di 
giurisdizione. Si entra nel campo del diritto 
internazionale privato e ci si chiede a quale legislazione 
sia sottoposto il rapporto giuridico e quale sia il giudice 
competente a dirimere un'eventuale controversia tra le 
parti. 

Si apre così un delicatissimo vaso di Pandora di 
questioni giuridiche che pervadono la scienza giuridica 
fin dai primi anni della diffusione delle tecnologie 
telematiche su scala internazionale. Quale criterio si 
utilizza per individuare la legge applicabile? La sede 
legale del service provider, oppure la sede in cui sono 
posti fisicamente i server, oppure ancora la zona 
geografica in cui viene offerto il servizio? Inoltre, il 
provider di un servizio offerto via Internet deve 
sottostare solo alle leggi del suo Paese o anche a quelle 
dei Paesi in cui offre il suo servizio, e in quale misura? È 
eventualmente possibile risolvere il problema attraverso 
una specifica indicazione contrattuale che elegge una 
legislazione applicabile e un foro competente? 

In un ventennio di evoluzione normativa e 
giurisprudenziale, nonché di approfondimenti dottrinali, 
la scienza giuridica ha fornito risposte a questi 
interrogativi. La situazione è tutt'altro che semplice e 
uniforme, anche per il semplice fatto che l'evoluzione 


delle tecnologie telematiche ha una velocità tale per cui 
il mondo del diritto non riesce a tenere il passo; e 
dunque spesso ci troviamo con nuove sfide che devono 
essere affrontate dalla prassi contrattuale e dalla 
giurisprudenza con un certo grado di “creatività” 
rispetto alle norme positive disponibili. 

La soluzione più agile e di solito applicata è quella di 
indicare nei termini di servizio (quindi nel contratto tra il 
provider e l'utente) sia la legge applicabile sia il foro 
competente. Si lascia alla contrattazione privata la 
gestione dei rapporti giuridici nascenti sul Web, ma tale 
soluzione non sempre è davvero risolutiva, perché deve 
poi di volta in volta confrontarsi con norme imperative 
nazionali che per loro natura non possono diventare 
facilmente derogabili attraverso una semplice previsione 
contrattuale; tra queste, non ultime, vi sono le norme 
sulla privacy (che sono senza dubbio diverse tra USA ed 
Europa). 

Come si può intuire, la via della scelta contrattuale 
della legge applicabile e del foro competente, anche se 
non sempre risulta ottimale agli occhi dei giuristi, senza 
dubbio è quella preferita dai service provider, i quali 
tendono a impostare i termini di servizio in Modo da 
tutelare il più possibile i loro interessi a scapito di quelli 
degli utenti. E più il service provider è grande e potente, 
più avrà la tendenza a imporre le sue regole senza 
particolari timori di essere contestato; se poi le 
statistiche confermano che solo una bassissima 
percentuale degli utenti legge davvero i termini d’uso 
prima di accettarli, il gioco è fatto. 


Nella Figura 1.4 troverete schematizzate le tre 
modalità tramite le quali cedere e acquisire creazioni 
tecnologiche, illustrate in questo paragrafo. 
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Figura 1.4 Schema sinottico del paragrafo “Quali vie per cedere e 
acquisire creazioni tecnologiche?”. 


Capitolo 2 


La tutela del software in 
Europa e in Italia 


Un po’ di storia: in principio 
era Il software libero 

“In principio era il software libero” è una frase a effetto 
che utilizzo spesso nelle mie lezioni e presentazioni e 
che comunica con efficacia il concetto che la creazione 
del software è iniziata e si è sviluppata per anni senza 
che vi fosse una tutela specifica da parte del diritto della 
proprietà intellettuale. L'esigenza da parte delle aziende 
produttrici di software di avere una tutela sulle loro 
creazioni è emersa in un secondo momento e, com'è 
facile intuire, è stata proporzionale all'interesse che il 
mercato ha man mano dimostrato verso questo settore. 

C'è da dire inoltre che, in una prima fase di diffusione 
delle tecnologie informatiche, il software non era 
nemmeno percepito come un bene commerciale 
“autonomo”; era più che altro considerato come il 
normale corredo dell'hardware, in quanto informazioni 
necessarie a far funzionare un calcolatore, una periferica 
o altro dispositivo. Il dibattito sulla tutela giuridica del 
software iniziò quando il mercato divenne più maturo, 


cioè quando l'hardware divenne più standardizzato e si 
iniziò a capire che si poteva vendere un calcolatore 
lasciando poi all'utente la scelta su quali programmi 
installarci a seconda delle specifiche esigenze. 


Il dibattito sulla scelta tra 
copyright e brevetto 


Le aziende di informatica che verso la fine degli anni 
Settanta iniziarono a voler tutelare i loro cospicui 
investimenti potevano guardare a due diversi modelli: 
quello del diritto d'autore e quello del brevetto per 
invenzione. Il primo concepito per tutelare le creazioni 
intellettuali come i testi, la musica, le immagini, i video; 
il secondo concepito invece per tutelare una soluzione 
innovativa a un problema tecnico e la sua applicazione 
industriale. 

Scaturì quindi un interessante dibattito nella comunità 
scientifica dei giuristi e degli economisti su quale fosse 
tra i due modelli quello più congeniale a quel nuovo tipo 
di creazione. A generare dubbi era proprio una 
caratteristica peculiare del software: la sua vocazione 
tecnico-funzionale, di creazione destinata alla soluzione 
di problemi e all'esecuzione di specifiche mansioni; 
caratteristica che lo avvicinerebbe alla categoria delle 
invenzioni industriali più che alle opere creative. D'altro 
canto, però, il software non ha necessariamente 
un'applicazione industriale (pensiamo a software con 
scopo puramente ludico e di intrattenimento come i 
videogames), requisito invece fondamentale per la 


brevettabilità di un'invenzione. Inoltre, la creazione di 
software è più simile a quella di scrittura di un testo 
tecnico che a quella di invenzione; gli sviluppatori, 
infatti, possono semplicemente scrivere un software che 
svolga delle funzioni note e senza alcuna attività 
inventiva, ma comunque utilizzando una sintassi, un 
linguaggio di programmazione e del codice del tutto 
Nuovo. 

A tal proposito, Giorgio Floridia fa una contorta ma 
illuminante argomentazione. 


Non sembra plausibile che il software sia qualificato o no come 
invenzione a seconda del risultato che sarà ottenuto mediante lo 
svolgimento della funzione programmata: così, ad esempio, da 
negare la qualificazione di invenzione se il programma è preordinato 
alla soluzione di un problema intellettuale come sarebbe un puro 
calcolo matematico, oppure alla soluzione di un problema editoriale 
come ad esempio una raccolta di leggi [...], oppure alla soluzione di 
un problema tecnico di produzione industriale come quello 
concernente un nuovo processo di fabbricazione [...], per giungere 
alla conclusione che solo in quest’ultimo caso si potrebbe parlare di 
invenzione industriale, ma non nei casi precedenti. Questa opinione 
non sembra plausibile perché confonde il programma come mezzo 
tecnico per ottenere lo svolgimento della funzione desiderata da 
parte del computer ed il risultato della funzione stessa: chiaro 
essendo che l'invenzione consiste nel modo di ottenere il 
funzionamento della macchina e non invece nel risultato finale 
ottenuto mediante la macchina funzionante. 


NOTA 

Giorgio Floridia, “Le creazioni intellettuali a contenuto tecnologico”, in 
Paolo Auteri, Giorgio Floridia, Vito Maria Mangini e altri, Diritto 
industriale. Proprietà intellettuale e concorrenza, Giappichelli, Torino, 
2005, cap. I, par. 5. 


A ogni modo, al di là di disquisizioni puramente 
teorico-dottrinali, la scelta fu guidata anche da 
valutazioni di carattere economico e pratico. 


La tutela brevettuale veniva vista con diffidenza dalle 
aziende produttrici di hardware: esse temevano che tale 
prospettiva, da un lato, avrebbe attribuito un eccessivo 
potere alle aziende di software e reso il mercato 
dell'hardware schiavo delle loro scelte di mercato, 
dall'altro lato avrebbe costituito un ostacolo alla libera 
utilizzazione dei computer e quindi alla loro 
valorizzazione commerciale. 

NOTA 

Così si esprime Giorgio Floridia in “Le creazioni intellettuali a 

contenuto tecnologico”, op. cit. 

Inoltre la tutela brevettuale, richiedendo un complesso 
passaggio amministrativo per il deposito, risultava 
troppo costosa e macchinosa per aziende ancora piccole 
ed emergenti quali erano le prime software house degli 
anni Settanta e Ottanta. Il rischio era dunque quello di 
soffocare un business ancora in fase di consolidamento e 
di veloce espansione. 

Fu in questo contesto di notevoli e intricati interessi 
economici che il legislatore statunitense nel 1980 fece la 
necessaria scelta di stabilire ex /ege quale disciplina 
applicare al software, e optò per la via del copyright. 
Non a caso l'atto legislativo in questione fu chiamato 
“Computer Software Copyright Act”, legge che andava a 
modificare il preesistente Copyright Act del 1976 e che 
aveva lo scopo di regolamentare e limitare i diritti 
esclusivi dei creatori dei programmi per elaboratore. 

L'esempio statunitense servì da modello e da 
apripista; nell'arco di un lustro quasi tutti i principali 
Paesi tecnologicamente avanzati si mossero nella stessa 
direzione: l'Australia nel 1984 (con il Copyright 


Amendment Act), la Francia e la Germania nel 1985 
(entrambe con legge ordinaria per la riforma della 
normativa preesistente sul diritto d'autore), la Gran 
Bretagna anch'essa nel 1985 (con il Copyright Computer 
Software Amendment:). 

Arrivò poi una direttiva europea a sgombrare il campo 
da ulteriori dubbi su quale fosse la direzione da 
prendere nei Paesi della Comunità Europea (oggi Unione 
Europea): la direttiva n. 91/250/CEE, che appunto 
mirava a un’armonizzazione delle norme comunitarie in 
fatto di protezione del software e obbligava gli Stati 
membri ad applicare al software la normativa del diritto 
d'autore. La nuova opera doveva essere considerata alla 
stregua di un’opera letteraria ai sensi della Convenzione 
di Berna per la protezione delle opere letterarie e 
artistiche (adottata nel 1886 e sottoscritta da buona 
parte dei Paesi industrializzati del pianeta). 

In effetti, se si pensa alle peculiarità tecniche del 
software, la sua assimilazione a un’opera letteraria non 
pare nemmeno molto forzata; come già accennato, 
possiamo equiparare il programma in forma di codice 
sorgente a un manuale di istruzioni tecniche redatte in 
un preciso linguaggio e destinate alla macchina (0, al 
massimo, ad altri sviluppatori che conoscono quel 
linguaggio). La rilevanza dei requisiti di creatività e di 
originalità (tipici del diritto d'autore) tende quindi a 
prevalere sulla vocazione funzionale del software. Infatti, 
la soluzione tecnica cui un programma è preposto può 
essere raggiunta da programmatori diversi attraverso 
linguaggi diversi, architetture diverse, sintassi diverse; 


allo stesso modo in cui autori diversi possono scrivere 
diversi manuali di chimica scegliendo di illustrare e 
spiegare i vari principi della chimica con linguaggi 
diversi, con esempi diversi, con grafici diversi. 


La direttiva UE del 1991 e le 
nuove norme della legge 
italiana sulla tutela del 
software 


Abbiamo spiegato che fu il legislatore europeo a 
prendere una posizione netta e a indicare con una 
direttiva rivoluzionaria la strada da seguire per tutti i 
Paesi membri dell’Unione Europea. Come ogni direttiva, 
anche la n. 91/250/CEE forniva solo indicazioni di 
massima e lasciava un certo margine d'azione ai 
legislatori nazionali. 

L'articolo 1 chiarisce quale sia l'oggetto della tutela e 
quindi quale sia il campo d'azione di queste nuove 
norme. Ci fornisce inoltre una definizione di che cosa 
debba intendersi per “software” ai sensi della direttiva e 
delle norme nazionali che dovranno recepirla. 


1. Conformemente alle disposizioni della presente direttiva, gli Stati 
membri tutelano i programmi per elaboratore, mediante diritto 
d'autore, come opere letterarie ai sensi della Convenzione di Berna 
sulla tutela delle opere letterarie e artistiche. Ai fini della presente 
direttiva, il termine “programma per elaboratore” comprende il 
materiale preparatorio per la progettazione di un programma. 


2. La tutela ai sensi della presente direttiva si applica a qualsiasi 
forma di espressione di un programma per elaboratore. Le idee e i 
principi alla base di qualsiasi elemento di un programma per 


elaboratore, compresi quelli alla base delle sue interfacce, non sono 
tutelati dal diritto d'autore a norma della presente direttiva. 


3. Un programma per elaboratore è tutelato se originale, ossia se è il 
risultato della creazione intellettuale dell'autore. Per determinare il 
diritto alla tutela non sono presi in considerazione altri criteri. 

Si noti l’espressa equiparazione tra software e opere 
letterarie, che appunto rispecchia quanto abbiamo 
spiegato poco sopra. Interessante anche il passaggio in 
cui si sottolinea che le idee e i principi alla base di 
qualsiasi elemento di un programma restano esclusi 
dalla tutela del diritto d'autore. Ai fini della tutela non 
contano le funzionalità ma l'architettura e la sintassi del 
codice; in altre parole, non conta tanto ciò che un 
software fa, quanto come è stato progettato e 
sviluppato. Le interfacce a loro volta sono escluse dalla 
tutela di copyright come software, ma possono essere 
tutelate come opere grafiche se raggiungono un 
sufficiente livello di creatività e originalità. 

Come spesso accade, il legislatore italiano si distinse 
per inerzia e non prese iniziative particolari fino 
all'avvento della già citata direttiva europea. E anche 
nella norma di recepimento (il D.Lgs. n. 518/1992) in 
buona parte si limitò a riprodurre pedissequamente il 
testo della direttiva. 

Tale decreto legislativo inserì nella legge sul diritto 
d'autore una serie di articoli ad hoc per il software 
nonché una nuova apposita sezione della legge ossia la 
Sezione VI del Capo IV, intitolata proprio “Programmi per 
elaboratore”. E nell'articolo 2 LDA, norma che elenca le 
categorie di opere dell'ingegno tutelate dal diritto 
d'autore italiano, venne aggiunto un punto n. 8, che 


infatti non fa altro che parafrasare il testo dell'articolo 1 
della direttiva appena menzionato. 


Brevetto software: sì, no, 
forse... 


Dopo che le scelte legislative degli anni Ottanta e 
Novanta avevano indicato la strada del copyright a 
scapito del brevetto, il dibattito sulla tutela del software 
non si assopì del tutto e a tratti registrava qualche voce 
a favore di un’introduzione della possibilità di 
brevettazione. E non come soluzione sostitutiva del 
copyright, bensì come soluzione aggiuntiva e 
complementare al copyright. Il software sarebbe quindi 
diventato uno dei più importanti casi di creazione 
intellettuale soggetto a una duplice tutela, o forse 
triplice se aggiungiamo la prassi ormai radicata di 
sfruttare l'istituto del segreto industriale sul codice 
sorgente. 

L'aspetto bizzarro era che tra queste voci vi erano 
anche quelle di alcune aziende che invece solo un 
decennio prima avevano spinto decisamente verso la 
strada del copyright perché ritenuta meno complessa e 
dispendiosa. Una volta uscite dal mondo delle startup e 
diventate solide aziende multinazionali, quasi 
monopoliste nel loro settore, quelle stesse realtà 
magicamente avevano cambiato idea e iniziavano a 
trovare appetibile la strada del brevetto. 

Il dibattito arrivò presto anche nelle corti statunitensi, 
che, sfruttando il diverso livello di “creatività giuridica” 


consentito ai giudici degli ordinamenti di common law, 
iniziarono a delineare alcuni casi di applicabilità del 
modello brevettuale al software in sovrapposizione al 
copyright e in sostanza a legittimare la prassi. L'ultimo 
step fu opera dell'Ufficio Brevetti degli Stati Uniti 
(USPTO), il quale nel 1996 pubblicò un documento 
intitolato Final Computer Related Examination 
Guidelines (Linee guida definitive per l'esame dei 
brevetti relativi ai computer) nel quale si stabiliva: 


L'applicazione pratica di un’invenzione relativa al computer è 
passibile di brevettazione. Questo requisito può essere separato dai 
divieti variamente formulati contro la brevettazione di idee astratte, 
leggi della natura o fenomeni naturali. 


NOTA 

Testo originale: “A practical application of a computer-related 
invention is statutory subject matter. This requirement can be 
discerned from the variously phrased prohibitions against the 
patenting of abstract ideas, laws of nature or natural phenomena”. 
La versione integrale del documento è disponibile qui: 


L'USPTO iniziò quindi ufficialmente ad accettare 
brevetti per quelle che vengono più propriamente 
chiamate “computer implemented inventions” (ossia, 
invenzioni implementate attraverso il computer) ma che 
di fatto integrano una brevettazione di algoritmi e 
codice dunque di semplice software. 

Il dibattito non riguardò solo gli USA ma arrivò anche 
da quest'altra parte dell'oceano, pur con qualche anno 
di ritardo. Si giunse quindi a una proposta di direttiva 
europea che aprisse formalmente la strada alla 
brevettazione di software anche nel vecchio continente: 


la Proposta di Direttiva CE COM(2002)0092 sulla 
brevettabilità delle invenzioni a mezzo elaboratore. 
L'iter di approvazione (Francesco Paolo Micozzi 
nell'articolo “| software e i brevetti” offre una breve 
cronologia della proposta di direttiva. L'articolo è uscito 
sul numero 31 del 2005 della rivista LinuxPro ed è 
disponibile liberamente online sul sito dell'autore: 
fermamente bloccato dal Parlamento Europeo con una 
storica votazione ad amplissima maggioranza che si è 


ha chiuso definitivamente un acceso confronto politico 
durato circa cinque anni. Visto il risultato schiacciante, 
la Commissione Europea all’epoca dichiarò che non 
avrebbe più riprovato a proporre una direttiva volta a 
introdurre la brevettazione di software. 

Ciò nonostante, almeno negli USA i brevetti software 
rimangono una realtà ormai consolidata. E in Unione 
Europea, pur con la netta decisione del Parlamento, le 
aziende software riescono lo stesso a ottenere 
dall'Ufficio Brevetti Europeo la registrazione di 
“computer implemented invention” sfruttando 
l'elasticità delle maglie del sistema. Benché sia 
indiscusso il divieto di brevettare software in sé, le 
aziende interessate a ottenere una tutela brevettuale 
trovano il modo di “camuffare” le domande di brevetto e 
di dimostrare che l'invenzione oggetto della domanda di 
brevetto non è “puro software” ma è qualcosa di più 


complesso di cui il software è solo una componente 
(anche se il più delle volte è la componente principale). 
Tant'è che ancora oggi con ciclicità riemergono studi e 
pareri da voci anche autorevoli che rilanciano verso la 
brevettazione del software anche per il vecchio 
continente (a tal proposito si legga “I brevetti software 
sono morti, viva i brevetti! ”, articolo di Carlo Piana per 


Interlex.it, http://ww.interlex.it/copyright/c piana6. htm) - 


Senza dubbio è un tema che tende ad assumere (a 
volte anche in modo eccessivo) una connotazione 
ideologica. Le critica più comune è riassumibile nella 
frase “brevettando un software, si brevetta il problema e 
non la soluzione”; altre critiche importanti stigmatizzano 
la deriva verso una brevettazione compulsiva che per 
ragioni intuibili favorisce le grandi aziende a scapito 
delle piccole startup. Formalizzare, registrare e 
difendere un brevetto ha dei costi molto elevati, dunque 
le aziende che hanno alle spalle grandi capitali sono di 
certo più portate a brevettare; a volte anche solo per 
tenere occupato un campo di sviluppo (il tipico “mettere 
una bandierina”) e non per innovare davvero. Ciò va 
nella direzione esattamente opposta rispetto allo spirito 
originario del brevetto, che appunto dovrebbe essere 
quello di incentivare l'innovazione. 

L'amico Carlo Piana, nel suo libro Open source, 
software libero e altre libertà. Un’introduzione alle 
libertà digitali (liberamente scaricabile all’URL 
commentato una nota sentenza sul tema dei brevetti 
software: la sentenza della Corte d'Appello per il Circuito 


Federale USA nel caso “Intellectual Ventures v. 
Symantec”. Soffermandosi in particolar modo sulla 
dissenting opinion del giudice Mayer, Piana ha distillato 
i principali punti deboli del sistema di brevettazione 
software statunitense, che in sintesi sono i seguenti: 
l'ampiezza della protezione offerta dal brevetto è 
sproporzionata rispetto al valore di ciò che viene 
“rivelato” con il brevetto; l'incentivo all'innovazione 
viene dato in un momento sbagliato; il numero 
(eccessivo) di brevetti concessi ne fa un problema in sé; 
i brevetti software per loro natura mancano dei naturali 
confini che i brevetti di norma offrono negli altri campi. 


I diritti degli autori di 
software 


Assumendo quindi che sia chiusa la diatriba sui 
brevetti e che nell'Unione Europea il software rientri 
indiscutibilmente nel campo d'azione del diritto 
d'autore, passiamo ora a vedere più nel dettaglio quali 
diritti vengono riservati agli autori di software. 
Utilizzeremo come riferimento normativo la legge 
italiana, la quale comunque, come già accennato, in 
questa parte non fa altro che riprodurre quasi 
pedissequamente il testo della direttiva del 1991. 

L'autore del software ha sulla sua opera in genere gli 
stessi diritti esclusivi di utilizzazione economica che 
hanno gli autori di opere più “classiche” come le opere 
letterarie, le opere musicali, le opere fotografiche; li 
abbiamo già elencati nel capitolo 1. 


Ora però vediamo più nel dettaglio quali sono i diritti 
nello specifico riservati agli autori di software; li 
troviamo nell'articolo 64-bis LDA, che recita: 


Fatte salve le disposizioni dei successivi articoli 64-ter e 64-quater, i 
diritti esclusivi conferiti dalla presente legge sui programmi per 
elaboratore comprendono il diritto di effettuare o autorizzare: 


a) la riproduzione, permanente o temporanea, totale o parziale, del 
programma per elaboratore con qualsiasi mezzo o in qualsiasi forma. 
Nella misura in cui operazioni quali il caricamento, la visualizzazione, 
l'esecuzione, la trasmissione o la memorizzazione del programma per 
elaboratore richiedano una riproduzione, anche tali operazioni sono 
soggette all’autorizzazione del titolare dei diritti; 


b) la traduzione, l'adattamento, la trasformazione e ogni altra 
modificazione del programma per elaboratore, nonché la riproduzione 
dell’opera che ne risulti, senza pregiudizio dei diritti di chi modifica il 
programma; 


c) qualsiasi forma di distribuzione al pubblico, compresa la locazione, 

del programma per elaboratore originale o di copie dello stesso. [...] 

Come si può notare, si tratta di tre diritti esclusivi in 
particolare riferiti al mondo del software, con chiari 
riferimenti alle forme di fruizione e utilizzo peculiari per 
quel tipo di opera dell’ingegno. 


Il principio dell’esaurimento 

Il punto c) del citato articolo 64-bis fa riferimento al 
concetto di “locazione del programma” che sta alla base 
del meccanismo della concessione del software in 
licenza. Come avremo modo di approfondire, a seconda 
di come viene strutturato il contratto, la cessione del 
software in licenza da un punto di vista giuridico è 
equiparabile a una locazione. 


Dopo il punto c), l'articolo 64-bis richiama il cosiddetto 
“principio dell’esaurimento del diritto”, secondo cui “la 
prima vendita di una copia del programma nella 
comunità economica europea da parte del titolare dei 
diritti, o con il suo consenso, esaurisce il diritto di 
distribuzione di detta copia all’interno della comunità, 
ad eccezione del diritto di controllare l'ulteriore 
locazione del programma o di una copia dello stesso”. Si 
tratta di un principio cardine del diritto della proprietà 
intellettuale, grazie al quale si evita che l’autore abbia 
un eccessivo controllo sulla distribuzione delle singole 
copie della sua opera. 

Fa eccezione all'esaurimento del diritto proprio il caso 
della locazione del software. Ciò spiega anche come mai 
il modello della licenza d'uso sia il più diffuso; con la 
licenza d'uso il titolare dei diritti d'autore può 
mantenere un maggior controllo sull'opera e, nei casi di 
violazione delle condizioni contrattuali, anche revocare i 
permessi d’uso al licenziatario. 

Anche la messa a disposizione del pubblico di opere in 
maniera che ciascuno possa avervi accesso dal luogo e 
nel momento scelti individualmente di cui all'articolo 16 
LDA viene espressamente esclusa dal principio 
dell’esaurimento. Da ciò si capisce anche come mai 
l'offerta di software e banche dati tramite accesso online 
(e quindi senza distribuzione di copie vere e proprie) sia 
una formula sempre più diffusa. 


Quali libertà per gli 
utilizzatori del software? 


Ai vari diritti esclusivi che consentono agli autori e loro 
aventi causa di controllare la diffusione e l'utilizzo delle 
opere protette, il diritto d'autore pone comunque dei 
“contrappesi”, stabilendo delle limitazioni per l'esercizio 
di tali diritti. Nella dottrina giuridica si parla per 
tradizione di “libere utilizzazioni” o più di recente di 
“eccezioni al diritto d'autore”, cioè situazioni nello 
specifico definite dalla legge che rappresentano delle 
aree franche in cui gli utilizzatori possono muoversi 
senza l'onere di ottenere un preventivo consenso e 
senza temere di subire conseguenze legali. 

Nell'ambito dell'utilizzo di software queste “aree 
franche” sono definite dagli articoli 64-ter e 64-quater 
LDA. 

Riportiamo integralmente le due norme. 

Articolo 64-ter 


1. Salvo patto contrario, non sono soggette all’autorizzazione del 
titolare dei diritti le attività indicate nell'art. 64-bis, lettere a) e b), 
allorché tali attività sono necessarie per l’uso del programma per 
elaboratore conformemente alla sua destinazione da parte del 
legittimo acquirente, inclusa la correzione degli errori. 


2. Non può essere impedito per contratto, a chi ha il diritto di usare 
una copia del programma per elaboratore, di effettuare una copia di 
riserva del programma, qualora tale copia sia necessaria per l’uso. 


3. Chi ha il diritto di usare una copia del programma per elaboratore 
può, senza l'autorizzazione del titolare dei diritti, osservare, studiare 
o sottoporre a prova il funzionamento del programma, allo scopo di 
determinare le idee ed i principi su cui è basato ogni elemento del 
programma stesso, qualora egli compia tali atti durante operazioni di 


caricamento, visualizzazione, esecuzione, trasmissione O 
memorizzazione del programma che egli ha il diritto di eseguire. Le 
clausole contrattuali pattuite in violazione del presente comma e del 
comma 2 sono nulle. 


Articolo 64-quater 


1. L'autorizzazione del titolare dei diritti non è richiesta qualora la 
riproduzione del codice del programma di elaboratore e la traduzione 
della sua forma ai sensi dell’art. 64-bis, lettere a) e b), compiute al 
fine di modificare la forma del codice, siano indispensabili per 
ottenere le informazioni necessarie per conseguire l’interoperabilità, 
con altri programmi, di un programma per elaboratore creato 
autonomamente purché siano soddisfatte le seguenti condizioni: 


a) le predette attività siano eseguite dal licenziatario o da altri che 
abbia il diritto di usare una copia del programma oppure, per loro 
conto, da chi è autorizzato a tal fine; 


b) le informazioni necessarie per conseguire l’interoperabilità non 
siano già facilmente e rapidamente accessibili ai soggetti indicati alla 
lettera a); 


c) le predette attività siano limitate alle parti del programma originale 
necessarie per conseguire l’interoperabilità. 


2. Le disposizioni di cui al comma 1 non consentono che le 
informazioni ottenute in virtù della loro applicazione: 


a) siano utilizzate a fini diversi dal conseguimento 
dell’interoperabilità del programma creato autonomamente; 


b) siano comunicate a terzi, fatta salva la necessità di consentire 
l’interoperabilità del programma creato autonomamente; 


c) siano utilizzate per lo sviluppo, la produzione o la 

commercializzazione di un programma per elaboratore 

sostanzialmente simile nella sua forma espressiva, o per ogni altra 

attività che violi il diritto di autore. 

Si noti il reiterato richiamo al concetto di 
“interoperabilità”. Secondo la definizione più comune, 


ripresa anche dalla stessa direttiva del 1991 al 


Considerando 10, per interoperabilità si intende la 
capacità di due o più sistemi informatici di scambiarsi 
informazioni e di usare reciprocamente le informazioni 
scambiate. Quindi la decompilazione consentita è anche 
quella mirata a ottenere l’interconnessione con un 
software diverso da quello decompilato, ma deve 
riguardare solo le parti del software necessarie a 
ottenere l’interoperabilità. 

3. Le clausole contrattuali pattuite in violazione dei commi 1 e 2 sono 

nulle. 

La norma termina con un comma 4, che però abbiamo 
deciso di non riportare. 

Interessante la disposizione del menzionato comma 3, 
il quale, indicando come nulle le clausole contrattuali 
che violano i due commi precedenti, va ad arginare una 
prassi molto diffusa nella distribuzione del software. Le 
grandi aziende produttrici di software sono infatti solite 
inserire nei loro contratti e nelle licenze d'uso clausole 
che impongono un divieto assoluto di decompilazione; 
per effetto di questo comma tali clausole divengono 
parzialmente nulle, cioè nulle nella parte in cui vietano 
attività espressamente consentite dai commi 1 e 2. 


Chi è di preciso il titolare dei 
diritti sul software? 


NOTA 
Questo paragrafo riprende i contenuti dell'articolo “Di chi sono i diritti 
sul software?”, uscito nel maggio del 2020 per il sito TechEconomy 


Nell'ordinamento italiano, il principio generale è 
quello secondo cui i diritti d'autore appartengono alla 
persona fisica che ha creato l’opera, cioè all'essere 
umano che ha estrinsecato un'idea creativa astratta 
sotto forma di opera. L'articolo 6 LDA sottolinea infatti 
che: 

il titolo originario dell'acquisto del diritto di autore è costituito dalla 

creazione dell’opera, quale particolare espressione del lavoro 

intellettuale. 

A questo principio generale fanno eccezione solo tre 
categorie di opere, inserite più di recente nella nostra 
legge, proprio quelle che abbiamo chiamato creazioni 
tecnologiche: il software, le banche dati e il design 
industriale. 

La direttiva all'articolo 2 (poi ripreso dall'articolo 12- 
bis LDA) innanzi tutto stabilisce che, in linea generale, 
come avviene negli altri campi della creatività umana, è 
considerato autore del software e dunque titolare 
originario dei diritti “la persona fisica o il gruppo di 
persone fisiche che ha creato il programma”. 

Tuttavia subito dopo precisa che: 


qualora i programmi siano creati da un lavoratore dipendente 

nell'esecuzione delle sue mansioni o su istruzioni del suo datore di 

lavoro, il datore di lavoro gode dell’esercizio esclusivo di tutti i diritti 

economici sul programma creato, salvo disposizioni contrattuali 

contrarie. 

La norma ci dice quindi che, in questo caso, i diritti di 
utilizzazione economica sul software vengono acquisiti 
in via originaria dal datore di lavoro e non appartengono 


agli sviluppatori in quanto persone fisiche. 


Si tratta di un'eccezione importante (che troviamo 
quasi identica anche nell’ambito delle banche dati e 
delle opere di design), che risponde a esigenze sia 
pratiche sia economiche. In sostanza, il legislatore 
europeo presuppone che questo tipo di creazioni di 
norma vengano concepite e create nell’ambito di un 
disegno aziendale e con un lavoro di squadra, più di 
quanto avvenga per la creazione di opere più classiche 
come le opere letterarie, le opere musicali, le opere 
fotografiche, le opere pittoriche. 

Soffermiamoci su due concetti chiave. 

Il primo: la norma precisa che quel principio vale solo 
se non vi sono disposizioni contrattuali contrarie (la 
legge italiana utilizza la formula “salvo patto contrario”); 
dunque di fatto la questione viene rimandata ai contratti 
di lavoro. | contratti nazionali di lavoro del settore 
informatico non indicano un patto contrario, ma ciò non 
vieta che i singoli rapporti contrattuali possano inserire 
una previsione di quel tipo, dal momento che si 
tratterebbe comunque di una modifica a favore del 
dipendente. 

Il secondo: si dice che deve trattarsi di un lavoratore 
dipendente nell'esercizio delle sue mansioni. Non basta 
quindi che l’autore del codice sia un dipendente, ma è 
necessario anche che lo sviluppo di software faccia 
espressamente parte delle sue mansioni. Anche a questo 
proposito, quindi, la questione va approfondita a livello 
di contratto di lavoro; è infatti nel contratto di lavoro che 
vengono descritte la mansioni del dipendente. 


Facciamo però attenzione a tutte quelle forme di 
collaborazione che da un punto di vista tecnico non 
rientrano nella definizione di lavoro subordinato e che 
vengono in genere ricondotte all'idea di lavoro “para- 
subordinato”, nelle quali lo sviluppatore partecipa alla 
creazione di un progetto aziendale ma lo fa con un 
inquadramento contrattuale che non lo qualifica come 
vero lavoratore dipendente e quindi lo tiene fuori dal 
campo d'azione dell'articolo 12-bis LDA. Pensiamo a 
situazioni (per altro oggi molto diffuse) come le 
collaborazioni a progetto, le collaborazioni a partita IVA 
con unico committente, gli stage e gli apprendistati; e in 
ambito scientifico e accademico le borse di studio, di 
dottorato e gli assegni di ricerca utilizzati in realtà per 
“stipendiare” collaboratori che di fatto ricoprono 
mansioni anche di sviluppo di software. In tutti questi 
casi non vi è certezza che scatti l'eccezione di cui 
all'articolo 12-bis, quindi per il datore di lavoro che 
decide di utilizzare una di queste forme di 
collaborazione è sempre buona prassi inserire nei 
contratti di collaborazione, nelle lettere di incarico 0 
addirittura nei bandi di selezione un’avvertenza 
esplicita in cui chiarisce che il copyright su tutto ciò che 
verrà sviluppato dal collaboratore sarà in automatico 
ceduto al datore di lavoro. 


Il software come opera 
derivata 


Sempre più raramente si progetta e si sviluppa 
software partendo da una tabula rasa, mentre sempre 
più spesso si parte da pacchetti software preesistenti e 
dunque da righe di codice già scritte per altre necessità 
che vanno quindi modificate e adattate. 

Le varie piattaforme di condivisione di codice (come 
GitHub, GitLab, Stack Overflow, Stack Exchange, Reddit 
e simili) permettono agli autori di software di poter 
visionare le soluzioni tecniche già sviluppate dai loro 
predecessori e anche di copiarle e riutilizzarle. Come 
risulterà ormai chiaro a chi è arrivato a leggere fin qui 
questo libro, il fatto che una creazione intellettuale sia 
messa a disposizione di tutti attraverso Internet non 
implica che essa sia anche liberamente riutilizzabile; a 
meno che vi sia associata inoltre una licenza d'uso che 
lo autorizzi espressamente. 

Torniamo quindi a quanto abbiamo già spiegato 
introducendo il concetto di “opera derivata”, e cioè che 
qualsivoglia riutilizzo di codice, ancor più quando mirato 
a realizzare un'opera derivata, dev'essere 
espressamente e preventivamente autorizzato dal 
titolare dei diritti. 

Se questa autorizzazione risiede in una licenza 
pubblica, è fondamentale non solo verificare se e in 
quali termini la licenza consenta l’attività di derivazione, 
ma anche interrogarsi su eventuali problemi di 
compatibilità tra licenze che possono nascere ex post. 
Come vedremo, alcune licenze open source 
condizionano la libertà di rielaborazione/derivazione al 
fatto che anche l’opera derivata sia rilasciata sotto la 


stessa licenza e che anche il codice “nuovo” dell’opera 
derivata sia esposto e distribuito (cosiddetto “copyleft” o 
“share alike”). È davvero un passaggio delicato, dato 
che potrà avere ripercussioni sul futuro del progetto e 
sul modello di business prescelto, perciò è importante 
che sia fatto con consapevolezza fin dall'inizio. A ogni 
modo, sul tema della compatibilità tra licenze open 
source torneremo più avanti. 

A tal proposito, però, è il caso di mettere subito a 
fuoco un concetto chiave, che si renderà determinante 
proprio in tema di gestione delle licenze open source: la 
differenza tra la semplice aggregazione di pacchetti 
software e la fusione di moduli software separati a 
formare un unico pacchetto. È determinante perché solo 
la seconda integra un'effettiva “derivazione” e quindi 
porta con sé tutti gli effetti tipici delle licenze con 
clausola copyleft. Per chiarire questo concetto riportiamo 
il testo di una FAQ diffusa dalla Free Software 
Foundation a mo' di linea guida. 


La “semplice aggregazione” di due programmi consiste nel metterli 
entrambi sullo stesso CD-ROM o disco fisso. Usiamo questo termine 
quando vogliamo indicare due programmi separati, che non siano 
parti di un singolo programma. In questo caso se uno è sotto GPL, 
non c’è alcuna restrizione per l’altro programma. 


Fondere due moduli vuol dire collegare i due componenti insieme in 
modo da formare un programma più grande. Se uno dei due è 
coperto da GPL, anche l'insieme dei due programmi deve essere 
coperto da GPL. Se questo non è possibile o è indesiderato, è 
possibile non farlo affatto. 


In cosa consiste la fusione di due parti per ottenere un programma? 
Questa è una questione legale, sulla quale l’ultima parola tocca ai 
giudici. Noi crediamo che un criterio ragionevole dipende sia dal 
meccanismo di comunicazione (esecuzione con “exec”, 


ridirezionamento dell'output, rpc, chiamate di funzione in uno spazio 
di indirizzamento condiviso, ecc.) che dalla semantica della 
comunicazione (che genere di informazione è scambiata). 


Se i moduli sono inclusi nello stesso eseguibile, sono decisamente lo 
stesso programma. Se i due moduli sono concepiti per girare 
collegati insieme in uno spazio di indirizzamento condiviso, questo 
vuol dire quasi sicuramente fondere due programmi in uno solo. 


AI contrario, ridirezionamento, uso dei socket e degli argomenti della 
riga di comando sono meccanismi di comunicazione normalmente 
usati tra due programmi separati. Quindi, quando sono usati per la 
comunicazione, i moduli sono programmi separati. Ma se la sintassi 
della comunicazione è abbastanza intima, e se c'è uno scambio di 
dati con una struttura complessa, anche questo può essere una base 
per considerare due moduli come parti di un programma più grande. 
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Figura 2.1 Interessante infografica che illustra efficacemente i rapporti di 
derivazione e integrazione tra pacchetti di software open source e che 
mette a fuoco la differenza tra “derived work” e “combined work”. 
L'infografica si trova su Wikimedia Commons 
(https://en.wikipedia.org/wiki/License_ compatibility#/media/File:Software- 


dalla monografia “The Rise of Open Source Licensing” di Mikko Valimaki 
(2005). 


Le norme penali a tutela del 
software 


Fin qui abbiamo parlato dei diritti sul software in 
un'ottica prettamente civilistica. Ma come abbiamo 
spiegato nel capitolo 1 il diritto d'autore prevede anche 
norme di carattere penale, le quali offrono una tutela 
aggiuntiva che entra in gioco nei casi più gravi, cioè 
quando si riscontra un comportamento antigiuridico 
definito dalla legge come reato. 

Nell'ordinamento italiano l'unica norma che individua 
e disciplina nello specifico i reati legati alla diffusione 
abusiva del software è l'articolo 171-bis, comma 1, LDA, 
che recita: 


Chiunque abusivamente duplica, per trarne profitto, programmi per 
elaboratore o ai medesimi fini importa, distribuisce, vende, detiene a 
scopo commerciale o imprenditoriale o concede in locazione 
programmi contenuti in supporti non contrassegnati dalla Società 
italiana degli autori ed editori (SIAE), è soggetto alla pena della 
reclusione da sei mesi a tre anni e della multa da euro 2.582 a euro 
15.493. La stessa pena si applica se il fatto concerne qualsiasi mezzo 
inteso unicamente a consentire o facilitare la rimozione arbitraria o 
l’elusione funzionale di dispositivi applicati a protezione di un 
programma per elaboratori. La pena non è inferiore nel minimo a due 
anni di reclusione e la multa a euro 15.493 se il fatto è di rilevante 
gravità. 


I comportamenti indicati come reati sono quindi di due 
tipi: quelli descritti nel primo periodo della norma, 
attinenti alla diffusione abusiva di software effettuata 
con fini di profitto e anche alla mera detenzione se 
questa è a scopo commerciale o imprenditoriale (rimane 


quindi fuori la detenzione a uso privato/personale); 
quelli descritti nel secondo periodo della norma, 
attinenti alla rimozione ed elusione dei sistemi 
tecnologici di protezione (in gergo chiamati DRM; ne 
parleremo più avanti). 

L'ultimo periodo della norma qui riprodotta riguarda 
invece un’aggravante che può addirittura portare alla 
reclusione in carcere. 


Tutele di natura tecnologica 
Fin qui abbiamo visto in che modo il creatore di un 
software può tutelare la sua opera da un punto di vista 
strettamente giuridico, cioè muovendosi solo sul piano 
dei diritti che l'ordinamento riconosce all'autore e delle 
azioni legali (civili e penali) esperibili contro chi viola 
questi diritti. Vi sono però altre forme di protezione di 

natura tecnologica che si aggiungono a quelle già 
previste dalle norme giuridiche e dalle previsioni 
contrattuali. Vediamo insieme le principali. 


La criptazione del codice sorgente 
e in generale delle specifiche 


tecniche 
Fin dai primi anni, i produttori di software pensarono 
che fosse opportuno porre un'ulteriore barriera oltre 
all’apposizione di un disclaimer che segnalasse la 
sussistenza del copyright (il classico a// rights reserved). 
Per evitare che gli utenti del software ne facessero usi 
che andassero al di là di quelli consentiti nelle licenze 


d'uso, si iniziò a distribuire il software unicamente sotto 
forma di codice binario (ovvero il codice leggibile solo 
dal calcolatore), senza quindi il relativo codice sorgente. 
Il codice sorgente, mostrando la reale sintassi e struttura 
del software, è infatti fondamentale per poter effettuare 
modifiche e adattamenti. Dunque la distribuzione in 
forma di semplice codice binario rende il software 
solamente installabile e utilizzabile così come fornito dal 
produttore, a meno che si faccia un complesso lavoro di 
ricostruzione ex post e di reverse engineering. 


NOTA 
Secondo la definizione più accreditata il reverse engineering è il 
processo di analisi di un sistema software esistente, eseguito al fine 
di crearne una rappresentazione ad alto livello di astrazione. 

A volte il codice sorgente viene fornito ma viene in 
qualche modo “offuscato”, ovvero reso deliberatamente 
difficile da comprendere per un lettore umano rendendo 
di conseguenza difficile anche il reverse engineering e la 
modifica del codice. 


I sistemi DRM 


L'acronimo DRM sta per digital rights management, 
letteralmente “gestione digitale dei diritti” (e non come 
alcuni sostengono “gestione dei diritti digitali”), e indica 
tutti i sistemi tecnologici di protezione con cui i titolari 
dei diritti di proprietà intellettuale possono controllare 
maggiormente le attività da parte degli utilizzatori. 
Classici esempi sono quegli script che, installati sui CD 
musicali e sui DVD video, non permettono la 
duplicazione del disco su un supporto vergine; questo 


genere di sistemi anticopia si diffuse nei primi anni 
Duemila quando, da un lato, le opere musicali e 
cinematografiche erano ancora distribuite per lo più su 
supporti fisici e, dall'altro lato, i masterizzatori 
divennero un oggetto relativamente economico e 
utilizzabile da tutti. Oggi i DRM sono applicati più che 
altro nella diffusione di opere digitali attraverso i vari 
store online o nelle payTV che utilizzano apposite 
consolle o schede per decriptare il segnale. 

Quella di applicare un DRM è una scelta molto 
invasiva, che spesso ha l’effetto collaterale di restringere 
l'esercizio di alcuni diritti che la legge sancisce a favore 
degli utilizzatori: pensiamo per esempio al diritto di 
effettuare una copia privata dell'opera a fini di “backup” 
o, nel campo del software, alle libertà (indicate negli 
articoli 64-ter e 64-quater LDA) di analizzare le 
funzionalità del software e di apportare interventi ai fini 
di garantire l’interoperabilità. 

Vi è poi una versione meno invasiva di DRM chiamata 
“social DRM” che non ha la funzione di inibire attività di 
copia e ridistribuzione, ma ha più che altro la funzione di 
inserire un watermark sulla copia digitale dell’opera, 
cioè una serie di metadati (teoricamente non 
modificabili e non rimovibili) con le informazioni relative 
al titolare dei diritti sul file o all'utente legittimo dello 
stesso. 


II cloud computing 
Un'altra soluzione per garantire maggior controllo al 
titolare dei diritti è quella di non fornire né il codice 


sorgente né l'eseguibile e di offrire il software in uso 
attraverso la Rete. Si parla in genere (forse con 
un'espressione un po’ ingenua) di cloud computing, una 
metafora secondo cui l'elaborazione dei dati non viene 
fatta sulla macchina dell'utente (che quindi funge 
unicamente da terminale “thin client”) ma su una 
“nuvola” ideale. Un noto meme che circola sui social 
media fa sarcasticamente notare che in realtà “non stai 
usando una nuvola, stai solo usando il computer di 
qualcun altro”. 

Il cosiddetto cloud computing quindi non riguarda solo 
la fruizione del software in sé; gli utenti utilizzano da 
remoto anche la potenza di calcolo del fornitore, il suo 
hardware, i propri sistemi informativi in senso più ampio. 
Si parla quindi a seconda dei casi di SaaS (Software as a 
Service), di PaaS (Platform as a Service) o di laaS 
(Infrastructure as a Service). 

Dunque il cloud computing e tutte le forme a esso 
assimilate realizzano una di quelle forme in cui in realtà 
il copyright (inteso come diritto di copia) diventa meno 
centrale, e al contrario diventa più centrale il contratto 
tra il fornitore e l'utente (i cosiddetti termini d'uso o 
termini di servizio). È infatti in quel contratto che si 
descrivono le modalità e i limiti entro cui l'utente può 
utilizzare il servizio cloud; ed è la violazione di quel 
contratto che può portare il fornitore a interrompere la 
fornitura o addirittura ad applicare sanzioni e penali. 


Forme di tutela “secondarie” 


Infine ci sono altre forme di tutela, che potremmo 
definire secondarie; esse non sono correlate in senso 
stretto allo sviluppo e alla diffusione del software, ma se 
applicate sapientemente hanno l’effetto di rafforzare il 
controllo sulla diffusione del software da parte del suo 
titolare. Alcune sono al limite della correttezza e sono 
fondate sull’instaurarsi di posizioni di mercato 
dominanti. Vediamo insieme le principali. 


Gli accordi di distribuzione 

Come abbiamo visto, tra i diritti esclusivi dei 
produttori di software vi è anche il diritto di distribuire 
copie. E in effetti una strategia per garantirsi un 
maggior controllo dei propri prodotti sul mercato è 
anche quella di stringere degli accordi di distribuzione 
che in qualche modo offrano una posizione 
“privilegiata” al proprio prodotto e nello stesso tempo 
penalizzino o addirittura escludano dalla rete di vendita 
i prodotti concorrenti. 

Un classico esempio è quello di una grande 
multinazionale che sviluppa un noto sistema operativo, 
la quale si accorda con i produttori di hardware affinché i 
computer vengano messi sul mercato con il suo sistema 
operativo preinstallato e anche affinché alcuni 
dispositivi siano impostati per funzionare correttamente 
solo con il suo sistema operativo. 

Gli utenti, dopo l'acquisto del dispositivo, saranno di 
fatto portati ad accettare la licenza d'uso del sistema 
operativo. In verità la legge comunque prevede la 
possibilità per l'utente di rifiutare la licenza e chiederne 


il rimborso; ma si tratta di una procedura complessa e 
che non porta un concreto vantaggio economico (il costo 
della licenza rimborsato è abbastanza esiguo), perciò gli 
utenti di solito la accettano ed eventualmente poi in una 
seconda fase installano un altro sistema operativo. Nel 
frattempo però in questo modo si è rafforzata 
ulteriormente la posizione dominante del produttore di 
quel sistema operativo; e ciò diventa ancora più 
palpabile se al sistema operativo vengono legati in 
modo indissolubile anche altri pacchetti software come il 
browser, il lettore multimediale, il programma di 
videoscrittura, e nel frattempo si progetta il sistema 
operativo per funzionare in modo ottimale con questi 
applicativi e per rendere la vita più difficile ad altri 
applicativi concorrenti. 

Siamo quindi nel campo non tanto del diritto della 
proprietà intellettuale quanto nel campo delle norme 
sulla concorrenza sleale. 


La diffusione di standard 
proprietari e il conseguente lock-in 


tecnologico 

Un modo davvero vincente per mantenere il controllo 
su un certo mercato e per riuscire a imporre il proprio 
prodotto software è quello di riuscire a diffondere uno 
standard tecnico proprietario. Per definizione, uno 
standard è una tecnologia che poi viene assunta come 
modello di riferimento e che in seguito per molto tempo 
è difficile scalzare e sostituire, a causa di quelli che 


vengono chiamati “effetti di rete”. Uno standard può 
essere aperto, cioè le sue specifiche tecniche sono 
liberamente conoscibili e riproducibili da chiunque 
senza incappare in problemi di copyright o brevetti; 
oppure può essere proprietario e quindi le sue specifiche 
tecniche sono nelle mani di un soggetto commerciale 
che ne controlla l’implementazione e lo sviluppo. 

Quello della diffusione di standard proprietari e il 
conseguente lock-in tecnologico è un tema alquanto 
sottovalutato. Me ne occupai approfonditamente nel mio 
libro del 2010 Apriti standard! (Apriti standard! 
Interoperabilità e formati aperti per l'innovazione 
tecnologica, Ledizioni, Milano, 2010); il libro è 
liberamente scaricabile all’URL https://aliprandi.org/books/apriti - 


non destasse particolare interesse rispetto ad altri temi 
più “mainstream” come il software open source e i 
brevetti software. In realtà credo che invece sia la vera 
chiave di volta di tutto l'ambito tematico delle 
tecnologie open e che fosse quello il “bandolo della 
matassa” per promuovere e diffondere un approccio 
“aperto” allo sviluppo software e hardware. 


Il Trusted Computing 
Uno dei fenomeni più invasivi e più restrittivi delle 
libertà degli utenti di software (e di hardware) è quello 
in genere denominato Trusted Computing, espressione 
che letteralmente significa “calcolo fidato” e quindi per 
estensione anche “informatica fidata”. Si tratta di una 
tecnologia escogitata e promossa da un consorzio di 


grandi aziende software, che, con il pretesto della 
maggior sicurezza e affidabilità, limita la possibilità da 
parte degli utenti di installare software sui loro 
dispositivi, i quali vengono predisposti per “accettare” 
unicamente software approvato e garantito (“trusted” 
appunto) dalla casa produttrice. Come spiega Wikipedia: 


il raggiungimento di questo scopo viene ottenuto inserendo in ogni 
dispositivo un chip, denominato Trusted Platform Module o più 
brevemente TPM, dotato di una coppia di chiavi crittografiche 
univoca per ogni chip, impossibili da modificare anche dal 
proprietario, e capace di generare altre chiavi per la crittografia di 


Capitolo 3 


Modelli contrattuali per 
cedere e acquisire 
software 


Il contratto e la fiducia 


NOTA 

Questo paragrafo riprende i contenuti dell'articolo “Firma di un 
contratto o fiducia?”, uscito nell'ottobre del 2017 per il sito 
TechEconomy (https://ww.techeconomy2030.it/2017/10/06/contratto-0- 


Circola un equivoco molto pericoloso secondo cui 
contratto e fiducia siano alternativi l’uno all'altra. Come 
se mettere nero su bianco un accordo fosse 
necessariamente un sintomo di mancanza di fiducia tra 
le parti; e come se a firmare contratti fossero solo 
persone malfidenti e insicure dei propri rapporti 
interpersonali. “Ma come, vuoi un contratto?! Allora non 
ti fidi di me?” sembra essere una frase molto in uso nel 
mondo della progettazione e realizzazione di tecnologia. 
Corollario di questo modo di pensare è la frase “prima 
iniziamo il lavoro, al contratto ci pensiamo dopo”, 
anch'essa molto diffusa; salvo poi arrivare a fine lavori 
senza che nulla sia stato messo per iscritto, trovandosi a 
litigare per incomprensioni emerse in corso d'opera e 


senza avere un riferimento scritto per poter ricostruire 
quali fossero davvero gli accordi. 

Sono tutti atteggiamenti che portano vantaggi solo a 
un'unica categoria: quella degli avvocati, i quali si 
trovano a dover risolvere con lunghe transazioni o 
addirittura cause giudiziali questioni che potevano 
essere chiarite senza problemi in una paginetta 
sottoscritta a inizio lavori. 

Dovremmo quindi sforzarci di uscire da questa 
mentalità e provare a vedere la questione da un'ottica 
sostanzialmente opposta: se un mio cliente o un mio 
consulente/fornitore insiste per mettere nero su bianco i 
termini della collaborazione significa che ho a che fare 
con un soggetto abituato a lavorare con serietà e 
secondo determinati standard; e dunque il mio livello di 
fiducia aumenta invece di calare. Ecco che, in 
quest'ottica, fiducia e contratto non sono più alternativi 
ma complementari tra loro. 

Ma di preciso che cos'è un contratto? Cerchiamo di 
capirlo meglio; in fondo, conoscere le cose le rende 
meno “spaventose”. 

Secondo la definizione molto chiara del nostro Codice 
Civile (articolo 1321): 


il contratto è l'accordo di due o più parti per costituire, regolare o 

estinguere tra loro un rapporto giuridico patrimoniale. 

In realtà, contrariamente all’immaginario collettivo, il 
contratto non è solo quello scritto; il contratto può 
essere anche concluso in forma orale (si veda il caso dei 
contratti conclusi dai call center telefonicamente), o 
anche attraverso un comportamento che esprima la 


volontà delle parti (si pensi al classico esempio dei 
distributori automatici di caffè o merendine, dove il 
semplice gesto di inserire la moneta e premere un tasto 
integra a tutti gli effetti un contratto di compravendita). 
Ciò nonostante in alcuni casi la legge indica 
espressamente che la forma scritta è necessaria per la 
validità del contratto (forma scritta ad substantiam) o 
per poter poi provare in giudizio l’esistenza del contratto 
(forma scritta ad probationem). 

Salvo il caso della cessione dei diritti (che come 
vedremo più avanti in Italia prevede la forma scritta ad 
probationem), i contratti di cui ci occupiamo in questo 
capitolo sono per lo più a forma libera e i modelli di 
solito utilizzati provengono in buona parte dalla prassi 
contrattuale statunitense, che per ovvie ragioni è stata 
la prima a cimentarsi con l'ambito dello sviluppo di 
tecnologie informatiche. 

Da ciò dipende che, tolti quei casi (che vedremo) in 
cui vi è una ben radicata prassi contrattuale da seguire, 
il contratto può risolversi in forme - per così dire - più 
“liquide”. In alcuni casi gli accordi tra le parti vengono 
definiti attraverso uno scambio di email, le quali però 
devono essere chiare, dettagliate, univoche e non 
ripudiabili, cioè devono poter essere ricondotte a un 
soggetto certo che abbia anche i poteri per impegnare 
l'azienda da un punto di vista giuridico. Un lungo, 
confuso e magari contraddittorio scambio di email 
costringerà, in caso di contestazioni tra le parti, a un 
lungo lavoro di ricostruzione del carteggio al fine di 
individuare la volontà contrattuale delle parti. 


In altri casi, come nei rapporti di mera consulenza, un 
preventivo sufficientemente dettagliato (con chiari 
obiettivi, scadenze, termini di pagamento) e 
controfirmato per accettazione può rappresentare esso 
stesso il contratto, o quantomeno diventa il principale 
documento per ricostruire il rapporto contrattuale in 
caso di contestazioni tra le parti. 

Detto questo, la via maestra, quella che mette al 
sicuro entrambe le parti da incomprensioni e da lunghe 
diatribe legali, rimane la redazione di un vero e proprio 
contratto, utilizzando i modelli contrattuali più solidi a 
disposizione e facendosi assistere da un legale esperto 
del settore. 


La cessione dei diritti e la 
regola della forma scritta 


Nel caso di cessione dei diritti esclusivi di utilizzazione 
economica (si veda il capitolo 1, ultimo paragrafo) 
l'ordinamento italiano pone un principio davvero 
fondamentale; tale principio è in sintesi espresso 
dall'articolo 110 LDA: 


La trasmissione dei diritti di utilizzazione deve essere provata per 

iscritto. 

Come si dice in gergo, si tratta di una forma scritta ad 
probationem e non ad substantiam; quindi l'atto 
giuridico del trasferimento dei diritti è valido anche 
senza la forma scritta, ma in caso di contestazione è 
necessario fornire prova scritta. 


Questa norma diventa spesso determinante nella 
risoluzione di questioni legali sulla titolarità dei diritti, 
dato che ha l’effetto di porre l'onere della prova a carico 
di colui che acquisisce i diritti (il cessionario o il 
licenziatario, a seconda dei casi) e dunque mette 
l'autore originario in una posizione privilegiata dal punto 
di vista probatorio. Quest'ultimo, infatti, in caso di 
contestazioni o diatribe sull'esercizio e sullo 
sfruttamento dei diritti d'autore, potrà solo limitarsi a 
dimostrare di essere l’autore dell’opera (per esempio 
producendo una prova di anteriorità temporale che lo 
qualifica in modo inequivocabile come primo creatore); 
mentre tutte le pretese e allegazioni dei licenziatari o 
cessionari dovranno essere da questi provate per 
iscritto. 

Ecco perché è prassi corretta e molto consigliata 
tenere sempre traccia scritta del trasferimento dei diritti 
e, ancor meglio, procedere sempre con la stipula di veri 
e propri contratti. Nella prassi comune, la prova scritta 
del trasferimento dei diritti può essere a volte 
riconosciuta anche in uno scambio di email, o 
nell’accettazione di un preventivo con piano di lavoro e 
descrizione dell’opera; ma la sottoscrizione di un 
contratto di cessione vero e proprio o l'accettazione di 
una licenza d'uso ben strutturata mettono al riparo da 
problemi interpretativi e probatori fastidiosi. 


I diversi rapporti giuridici che 
si instaurano nello sviluppo 


di software 


Un altro aspetto su cui spesso si crea confusione è sul 
tipo di rapporto giuridico instaurato tra chi sviluppa il 
software e chi poi sfrutterà/utilizzerà il software. 

Possiamo individuare tre scenari che all'apparenza 
sono simili, ma da un punto di vista giuridico sono molto 
diversi. Ed è fondamentale che chi si trova a cedere il 
software sviluppato in autonomia o, al contrario, ad 
acquisire il software sviluppato da qualcun altro sia 
consapevole di questa dicotomia e abbia chiaro in quale 
dei due scenari si trova. 

Il primo scenario vede Tizio sviluppare un software di 
sua iniziativa e con sue autonome scelte 
progettuali/creative e in seguito offrirlo a Caio, il quale, 
a seconda dei casi, lo utilizzerà per sé oppure ne 
acquisirà tutti i diritti per commercializzarlo. Nel 
secondo scenario, invece, Caio ha bisogno di un software 
che svolga delle specifiche funzioni e incarica Tizio di 
svilupparglielo. Infine, il terzo scenario: Tizio ha un 
software che presenta alcuni malfunzionamenti e bachi 
e che necessita di interventi sul codice; incarica dunque 
Caio come consulente informatico per scrivere alcune 
patch e rimetterlo in funzione. 

Le tre situazioni portano a un risultato di fatto molto 
simile (Tizio realizza del codice per poi darlo a Caio), ma 
la configurazione dei tre rapporti giuridici è senza 
dubbio diversa. 

Proprio su questi tre scenari e sui modelli contrattuali 
applicabili a ciascuno rifletteremo nei prossimi paragrafi. 


I contratti di progettazione e 
sviluppo software 


| contratti di progettazione e sviluppo software sono 
modelli di contratto da utilizzare per quei casi in cui un 
soggetto necessita di un software che svolga 
determinate funzioni e, non riuscendo a reperire sul 
mercato una soluzione adeguata, decide di farsela 
progettare e sviluppare ad hoc. 

La scienza giuridica italiana ha individuato a quali 
tipologie contrattuali tra quelle previste dal nostro 
Codice Civile è riconducibile il rapporto giuridico a 
seconda del soggetto che si occupa di sviluppare il 
software: il contratto di appalto e il contratto d'opera. 

Le norme che vedremo in questi paragrafi sono regole 
generali che il Codice Civile pone per tutti i contratti di 
appalto e d'opera senza distinzione di settore ed è facile 
intuire che, per poter applicare con successo tali 
tipologie contrattuali classiche al “nuovo” mondo del 
software (ricordiamoci che l'impianto del nostro Codice 
Civile è comunque del 1942), la prassi contrattuale ha 
dovuto sviluppare modelli specifici che variano a 
seconda delle esigenze e delle situazioni. Tra l’altro, 
visto che - come abbiamo già detto - il software è 
un’opera con un'evidente vocazione “funzionale”, cioè 
creata per svolgere specifiche operazioni, nei contratti di 
sviluppo software sono spesso inserite clausole molto 
dettagliate sul collaudo, sulle garanzie di 
funzionamento, sulla manutenzione nonché 


sull'assistenza con un orizzonte che quindi va oltre la 
data di consegna del lavoro. 


Il modello del contratto di appalto 

Il caso più comune prevede che il soggetto incaricato 
di sviluppare il software sia un'azienda, in qualsiasi sua 
forma, anche unipersonale; in questo caso si fa 
riferimento al contratto di appalto come definito 
dall'articolo 1655 del Codice Civile, cioè “il contratto con 
il quale una parte assume, con organizzazione dei mezzi 
necessari e con gestione a proprio rischio, il compimento 
di un’opera o di un servizio verso un corrispettivo in 
danaro”. Una definizione, dunque, in cui il focus del 
legislatore è posto sull'aspetto del rischio 
imprenditoriale. Seguono poi gli articoli con alcune 
regole generali per il rapporto tra committente e 
appaltatore. Secondo l'articolo 1656 l'appaltatore non 
può dare in subappalto l'esecuzione dell’opera o del 
servizio, se non è stato autorizzato dal committente; 
mentre secondo l’articolo 1659 l'appaltatore non può 
apportare variazioni alle modalità convenute dell’opera 
se il committente non le ha autorizzate, e tale 
autorizzazione deve essere provata per iscritto. 

Queste disposizioni sono appunto molto generiche e 
riguardano anche gli appalti di lavori molto diversi dalla 
progettazione e realizzazione di software (per esempio, i 
lavori di ristrutturazione affidati a un'impresa edile); ma 
comunque forniscono un'utile cornice di principi entro 
cui si può esprimere la libertà contrattuale delle parti. 


II modello del contratto d’opera 

A volte il committente si rivolge non a un'azienda 
bensì a un singolo sviluppatore che si pone come 
semplice persona fisica. Qui si ricade più propriamente 
nelle norme del contratto d'opera, ossia il contratto con 
cui una persona si obbliga a compiere dietro 
corrispettivo un’opera o un servizio, con lavoro per lo più 
proprio e senza vincolo di subordinazione nei confronti 
del committente (come da definizione dell'articolo 2222 
Codice Civile). Secondo l'articolo 2224, “se il prestatore 
d'opera non procede all’esecuzione dell’opera secondo 
le condizioni stabilite dal contratto e a regola d'arte, il 
committente può fissare un congruo termine, entro il 
quale il prestatore d'opera deve conformarsi a tali 
condizioni. Trascorso inutilmente il termine fissato, il 
committente può recedere dal contratto, salvo il diritto 
al risarcimento dei danni”. Inoltre “il committente può 
recedere dal contratto, ancorché sia iniziata l'esecuzione 
dell’opera, tenendo indenne il prestatore d'opera delle 
spese, del lavoro eseguito e del mancato guadagno” 
(articolo 2227). Per quanto riguarda situazioni in cui 
emergano vizi e difformità nel lavoro consegnato, 
entrano in gioco le disposizioni dell'articolo 2226. 

Una fattispecie particolare di contratto d'opera è il 
contratto d'opera intellettuale, che in sostanza differisce 
dalla fattispecie generale solo per il fatto che a 
sviluppare il software non è una semplice persona fisica 
ma è un libero professionista (classico esempio: un 
ingegnere informatico); le norme applicabili sono qui gli 
articoli 2230 e seguenti del Codice Civile. 


In questo caso la legge più che concentrarsi sul 
concetto di rischio imprenditoriale (come avviene nel 
contratto di appalto) si concentra sull'aspetto delle 
maggiori garanzie qualitative e deontologiche che 
dovrebbero in teoria dipendere dal superamento di un 
esame abilitativo e dall'iscrizione a un albo. La legge 
inoltre si concentra sul cosiddetto “intuitus personae”, 
cioè sul fatto che l’incarico professionale abbia una 
natura strettamente fiduciaria e che dunque debba 
essere il più possibile svolto dal professionista stesso o 
da collaboratori che operano sotto la sua direzione e 
responsabilità. A tal proposito si legga l'articolo 2232 
secondo cui “il prestatore d'opera deve eseguire 
personalmente l’incarico assunto. Può tuttavia valersi, 
sotto la propria direzione e responsabilità, di sostituti e 
ausiliari, se la collaborazione di altri è consentita dal 
contratto o dagli usi e non è incompatibile con l'oggetto 
della prestazione”. 


La cessione dei diritti nei contratti 


di sviluppo software 
Vi è poi l'aspetto della gestione della cosiddetta 
proprietà intellettuale sul codice realizzato. Sul tema, 
l'avvocato Nicola Ferrante fa giustamente notare: 


Il principale aspetto critico del contratto di sviluppo del software 
riguarda la titolarità dei diritti d'autore su quanto realizzato. Infatti, 
l'impresa che ha commissionato il programma potrebbe avere 
l'esigenza di diventarne l’esclusivo titolare, mentre il programmatore 
potrebbe avere interesse a mantenere la titolarità dei diritti 
patrimoniali, in modo da poter distribuire il programma anche a 
soggetti diversi dal committente. Per evitare problematiche, 


fondamentale sarà quanto previsto dal contratto, che dovrà sempre 
specificare in modo molto chiaro a chi spetta la titolarità dei diritti 
patrimoniali sul software (tratto dall'articolo “Contratto di sviluppo 
software” di Nicola Ferrante, disponibile online  all’URL 
https://ww.software.avvocatoferrante.it/contratto-sviluppo-software.html). 


La Figura 3.1 sintetizza i vari modelli contrattuali qui 
esposti. 

Un chiarimento per iscritto in merito alla titolarità di 
diritti sull'opera realizzata in esecuzione del contratto è 
senza dubbio fondamentale; in mancanza, le parti si 
espongono al rischio che in futuro emergano fastidiose 
diatribe su chi possa fare che cosa con il codice. Si presti 
attenzione al fatto che, nel caso si indichi nel contratto 
una cessione esclusiva dei diritti al committente, anche 
lo stesso sviluppatore non potrà più utilizzare lo stesso 
codice per altri progetti e per altri clienti. 


SOFTWARE MODELLO CONTRATTUALE 
SVILUPPATO DA DI RIFERIMENTO 


azienda contratto d'appalto 
(art. 1655 cod.civ.) 


libero professionista contratto d'opera intellettuale 


(art. 2230 cod.civ.) 


sviluppatore “semplice” | contratto d'opera -generico- 
(persona fisica) (locatio operis - art. 2222 cod.civ.) 


; contratto nazionale di lavoro 
lavoratore subordinato (art. 2094 cod.civ.) 


Figura 3.1 Modelli contrattuali per lo sviluppo di software. 





Le licenze software (in 
generale) 


Abbiamo già illustrato le nozioni fondamentali sulle 
licenze d'uso in generale; ora ci soffermeremo più nello 
specifico sulle licenze d'uso per software. | modelli di 
contratto analizzati fin qui in questo capitolo vengono 
utilizzati più che altro nell'ambito business to business 
(B2B), cioè in un ambito in cui tutti i soggetti sono 
soggetti professionali. Lo strumento contrattuale della 
licenza d'uso può essere utilizzato sia in ambito B2B 
(un'azienda acquisisce un software in licenza da parte di 
un’altra azienda), sia in ambito business to consumer 
(B2C). In questo secondo caso, si usa anche parlare di 
EULA, acronimo che sta per End-User License 
Agreement; e trattandosi di licenze rivolte all'utente 
finale (privato cittadino) entrano in gioco anche le 
cautele e le norme a tutela dei consumatori. 

Vedremo nei prossimi paragrafi quali sono i modelli 
contrattuali in cui la scienza giuridica ha inquadrato le 
licenze software e quali sono le relative implicazioni. 


Le licenze software: tra 


compravendita e locazione 
Nel linguaggio comune si sentono spesso espressioni 
come “ho comprato la nuova versione del sistema 
operativo Alfa” oppure “ho comprato una nuova 
applicazione per il mio smartphone”. A ben vedere, la 
scienza giuridica non è sempre concorde nel parlare di 


compravendita in ambito informatico perché in realtà 
non avviene un vero e proprio trasferimento di proprietà. 

Infatti, come ci ricorda l'articolo 1470 del Codice 
Civile, la compravendita è il contratto che ha per 
oggetto il trasferimento della proprietà di una cosa o il 
trasferimento di un altro diritto verso il corrispettivo di 
un prezzo. Bisogna quindi capire nel caso di 
un’acquisizione di software che cosa si intenda per 
“proprietà”. Abbiamo già spiegato che la proprietà di 
un’opera creativa (la cosiddetta “proprietà 
intellettuale”) si trasferisce con un contratto di cessione 
esclusiva dei diritti, e ciò avviene più che altro in ambito 
business to business. In ambito business to consumer, 
invece, un utente finale che reperisce sul mercato un 
nuovo software non diventa proprietario del software ma 
più propriamente acquisisce una serie di diritti di 
godimento e utilizzo sull'opera; mentre la proprietà 
rimane al produttore. L'unica cosa di cui diventa 
effettivamente proprietario, e per la quale si può parlare 
propriamente di compravendita, è il supporto su cui è 
fissato il software, cioè il CD, il DVD, la memory card; ma 
sappiamo che ormai sempre più raramente il software 
viene diffuso attraverso supporti fisici e sempre più 
spesso viene scaricato da Internet. 

Vi sono comunque alcune teorie che riconducono alla 
compravendita anche l'acquisizione dei diritti di utilizzo 
sull'opera; d'altronde, a fronte del versamento di un 
prezzo unitario, il venditore-licenziante cede la titolarità 
del supporto su cui il programma è installato e con essa 
anche il diritto di utilizzo del medesimo (così si è 


espressa una sentenza del Tribunale di Pisa del 18 
giugno 2015). 

Tuttavia l'approccio in genere più condiviso avvicina 
l'acquisizione di una licenza d'uso di software al modello 
contrattuale della locazione. Le stesse norme della LDA 
dedicate alla tutela del software, a loro volta derivate 
dalla direttiva del 1991, utilizzano proprio l’espressione 
“locazione del programma”; abbiamo avuto modo di 
parlarne a proposito del cosiddetto principio 
dell’esaurimento di cui all'articolo 64-bis. 

La locazione è definita dall'articolo 1571 del Codice 
Civile come il contratto con il quale una parte si obbliga 
a far godere all'altra una cosa mobile o immobile per un 
dato tempo, verso un determinato corrispettivo. Di 
norma la locazione è utilizzata per gli immobili (cioè 
quella che in maniera impropria viene chiamata 
“prendere in affitto una casa”) o per i beni mobili 
(pensiamo per esempio al leasing di un'automobile). La 
differenza di fondo tra la locazione vera e propria e la 
licenza d’uso di un’opera creativa come il software sta 
nel fatto che quest’ultima non si riferisce a una cosa 
mobile o immobile bensì a un bene immateriale 
(un’opera dell'ingegno, appunto). 


Le varie categorie di licenze per 
software 
Abbiamo già parlato in senso più generale della 
distinzione tra licenza proprietaria e licenza open; e 
spiegheremo nei prossimi capitoli che è stato proprio 


nell’ambito del software che ha preso forma perla prima 
volta quella distinzione. 

È però utile fin da subito tracciare le differenze di 
massima di questi due diversi e contrapposti approcci 
per la distribuzione di software. 

A rappresentare in modo molto efficace le due 
categorie, soccorre uno schema che circola da molti anni 
e che riportiamo nella Figura 3.2. 


Proprietary Software 








Figura 3.2 Infografica delle varie categorie di software secondo l'approccio 
della Free Software Foundation. L'immagine è disponibile su Wikimedia 
Commons 
(https://en.wikipedia.org/wiki/Software_license#/media/File:Software Categ 


A sinistra abbiamo il mondo del software libero e open 
source, indicato anche come un unico acronimo 
comprendente tutte le sue declinazioni: FOSS, cioè Free 
and Open Source Software (o a volte anche FLOSS, cioè 
Free Libre and Open Source Software). Avremo modo di 
riprendere questo argomento molto nel dettaglio e di 
comprendere meglio i vari sottoinsiemi della figura. A 
destra invece abbiamo il mondo del software 
proprietario, che in alcuni casi (benché numericamente 
minori) può anch'esso avere il codice sorgente 
disponibile o essere offerto in modo gratuito: il 
cosiddetto freeware, le versioni trial, le app gratuite che 
però servono per accedere a un servizio a pagamento, e 
altri esempi simili. Sovrapposta a questi due grandi 
riquadri, aleggia una terza categoria “trasversale”: 
quella del software liberamente scaricabile; per dire che 
il fatto che un software sia liberamente scaricabile non è 
indicativo di per sé del modello di licensing applicato. 

Nell'ambito delle licenze di software proprietario 
rientrano anche le cosiddette licenze OEM, acronimo che 
sta per Original Equipment Manufacturer, ossia 
“produttore di apparecchiature originali”. In questo caso 
il produttore dell'hardware crea un particolare legame 
con alcuni prodotti software specifici e li dichiara 
“certificati”, quasi a voler indicare che l'hardware in 
questione, per come è progettato, funzionerà in modo 
ottimale con un sistema operativo specifico o con degli 
applicativi specifici. In realtà questa scelta quasi sempre 
è dettata non tanto da effettive esigenze tecnologiche, 
quanto da accordi commerciali tra i big dell'hardware e i 


big del software. Ne consegue quindi che, per scelta del 
produttore dell'hardware, la licenza d'uso diventi 
implicita nell'acquisto del dispositivo, poiché il 
produttore dell'hardware ha sottoscritto con il produttore 
del software un accordo con facoltà di cedere le licenze 
d'uso del software agli acquirenti dei dispositivi venduti 
con il proprio marchio. 

In questo modo, da un lato il prezzo di acquisto della 
licenza software diventa sensibilmente più basso per 
l'utente finale rispetto al prezzo di norma praticato per 
la licenza standard (e questo è senza dubbio un 
vantaggio); dall'altro l'utente finale perde gran parte 
della sua possibilità di scelta sui prodotti software da 
installare su quel dispositivo. L'acquirente si trova di 
fatto a dover accettare i termini di licenza del sistema 
operativo e dei vari prodotti software “nativi” fin dal 
primo avvio del dispositivo. La legge italiana prevede 
comunque la possibilità di rifiutare tali licenze e di 
chiederne il rimborso; tuttavia nei fatti la richiesta di 
rimborso si rivela sempre laboriosa e dispendiosa. 


I contratti di 
somministrazione di servizi 
software 


La soluzione di non acquisire software ma di optare 
per la sottoscrizione di un servizio software 
esternalizzato e accessibile via Internet è sempre più 
diffusa. A volte viene scelta per ragioni tecniche, come 
per esempio la maggior sicurezza garantita da un server 


costantemente presidiato da professionisti IT e situato in 
server farm a prova di disastro, o la maggiore potenza di 
calcolo garantita da una macchina più performante e 
perfettamente ottimizzata. 

In realtà l'idea di concedere l’accesso al software come 
servizio fruibile in Rete e non come copia installabile è 
abbastanza “antica”, ma la sua diffusione è stata 
direttamente proporzionale con la diffusione della 
connettività internet e con l'allargamento della banda 
disponibile. 

Come abbiamo già precisato, da un punto di vista 
giuridico, il modello Software as a Service (SaaS) 
comporta sostanziali differenze rispetto alla cessione di 
diritti sull'opera e rispetto alla licenza d'uso, e si 
avvicina piuttosto al contratto di somministrazione. ll 
titolare del copyright sul software riveste più che altro il 
ruolo di service provider. 

Secondo la definizione offerta dall'articolo 1559 
Codice Civile la somministrazione è il contratto con il 
quale una parte si obbliga, verso corrispettivo di un 
prezzo, a eseguire, a favore dell'altra, prestazioni 
periodiche o continuative di cose. L'elemento 
caratterizzante di tale contratto è dunque una 
prestazione continuativa o periodica in cambio di una 
contropartita economica. La legge italiana non indica 
una specifica forma per questo contratto, che quindi 
rimane un contratto a forma libera; anche se la prassi 
giuridica e la giurisprudenza suggeriscono vivamente la 
forma scritta. 


Non siamo più tanto nell’ambito dell’utilizzazione di 
un'opera dell'ingegno (e quindi ci allontaniamo anche 
dal campo d'azione del diritto d'autore), quanto in 
quello della sottoscrizione di un servizio con il quale il 
fornitore non ci offre solo il mero utilizzo del software, 
ma anche una serie di prestazioni aggiuntive, come 
l'assistenza, la manutenzione, l'aggiornamento, la 
conservazione di dati, fino ad arrivare alla vera e propria 
intermediazione (come per esempio nel caso delle 
piattaforme per la fatturazione elettronica). 

Nel mercato dell'informatica di oggi è una formula 
sempre più diffusa, sia nel settore B2B, sia in quello 
B2C: basti pensare ai servizi di gestione di posta 
elettronica, alle piattaforme per la didattica a distanza, 
agli applicativi di office automation offerti in cloud (si 
vedano Google Docs e MS Office 365), le già citate 
piattaforme per la fatturazione elettronica e più in 
generale per la gestione di adempimenti fiscali e 
previdenziali. 

Questi contratti per certi versi possono essere 
avvicinati anche ai cosiddetti “contratti per adesione”, 
cioè quei contratti il cui contenuto è standardizzato e 
deciso da uno solo dei contraenti; le altre parti possono 
scegliere unicamente se aderire a quelle condizioni 
standard o rinunciare. A tal proposito, l'articolo 1341 del 
nostro Codice Civile precisa che le condizioni dei 
contratti predisposte da uno dei contraenti sono efficaci 
nei confronti dell'altro se al momento della conclusione 
del contratto questi le ha conosciute o avrebbe dovuto 
conoscerle usando l’ordinaria diligenza. Inoltre lo stesso 


articolo indica tutta una serie di clausole che devono 
essere espressamente approvate per iscritto dalla parte 
aderente: “le previsioni che stabiliscono, a favore di 
colui che le ha predisposte, limitazioni di responsabilità, 
facoltà di recedere dal contratto o di sospenderne 
l'esecuzione, ovvero sanciscono a carico dell'altro 
contraente decadenze, limitazioni alla facoltà di opporre 
eccezioni, restrizioni alla libertà contrattuale nei rapporti 
con i terzi, tacita proroga o rinnovazione del contratto, 
clausole compromissorie o deroghe alla competenza 
dell'autorità giudiziaria”. 

Per intenderci, questa norma è il motivo per cui in 
alcuni contratti è richiesta una doppia firma. E da essa 
deriva tutta una serie di problemi di compatibilità tra i 
modelli contrattuali italiani e quelli di importazione 
statunitense, che invece non contemplano questo 
obbligo aggiuntivo. Questione non da poco dato che, da 
un lato, per il diritto italiano la mancanza della doppia 
firma può inficiare il consenso, dall'altro buona parte dei 
servizi di cloud computing vengono offerti da grandi 
provider statunitensi che attraverso i contratti stessi 
“impongono” ai loro utenti di accettare l'applicazione 
della legge USA al rapporto contrattuale. 


Gli accordi di non 
divulgazione e la tutela del 
know-how tecnologico 


Abbiamo già spiegato che il copyright non si occupa di 
tutelare le idee in sé o le semplici informazioni, ma solo 


le opere dell'ingegno; e abbiamo già menzionato la 
disposizione della direttiva UE del 1991 secondo cui “le 
idee e i principi alla base di qualsiasi elemento di un 
programma per elaboratore, compresi quelli alla base 
delle sue interfacce, non sono tutelati dal diritto 
d'autore”. 

Sappiamo però che in alcuni casi un’idea astratta ha 
necessità di essere comunque protetta, ancor prima che 
essa prenda la forma di una creazione intellettuale 
tutelata da diritto d'autore o di un'invenzione industriale 
tutelata da brevetto. Pensiamo al caso di uno 
sviluppatore che vuole realizzare una nuova 
applicazione, tuttavia le sue competenze e le sue risorse 
economiche non sono sufficienti; dunque pensa di 
chiedere a una software house più grande e attrezzata di 
avviare una partnership. Lo sviluppatore si troverà a 
dover illustrare ai responsabili della software house la 
sua idea in una fase in cui l’idea non ha ancora preso 
una forma concreta ed è dunque esposta al rischio di 
essere replicata dalla software house senza che lui 
venga coinvolto. Nello stesso tempo, se lo sviluppatore 
dovesse rimanere reticente e non volesse illustrare 
l'idea, difficilmente la software house accetterebbe di 
finanziare e sostenere il progetto. 

Sappiamo anche che in alcuni casi una semplice 
informazione, che di per sé non sarebbe tutelabile con 
diritto d'autore, assume un valore economico elevato 
proprio perché pochissime persone ne sono a 
conoscenza. Se un software ha una struttura molto 
complessa e per farlo funzionare nel modo corretto è 


necessario possedere un “trick” che solo Tizio conosce, 
Tizio verrà più spesso incaricato come consulente dalle 
varie aziende e quindi nello stesso tempo avrà tutto 
l'interesse a che i suoi clienti non diffondano questa 
informazione. 

Come tutelarsi dunque in situazioni di questo tipo? Di 
solito ci si serve dei cosiddetti accordi di non 
divulgazione, anche noti con l'acronimo NDA (dalla 
dizione anglofona “non disclosure agreement”): contratti 
in cui una o più parti si impegnano, da un lato, a 
individuare le informazioni coperte dall'accordo e, 
dall'altro, a non diffondere e nel caso a non utilizzare 
nemmeno per intero tali informazioni. A sostegno di 
questa obbligazione contrattuale di norma si stabilisce 
per contratto una penale molto alta a carico della parte 
che dovesse violare il segreto; l'indicazione della penale 
è tra l’altro un utile strumento per quantificare il valore 
economico attribuito a quell’informazione. 

AI di là della sottoscrizione di contratti di segretezza 
(cosa che è sempre comunque consigliata), 
l'ordinamento giuridico già prevede delle norme sulla 
tutela del cosiddetto “segreto industriale”, o in senso più 
ampio “segreto commerciale”. Si tratta degli articoli 98 e 
99 del Codice della proprietà industriale. La prima delle 
due norme al comma 1 stabilisce che sono tre i requisiti 
che le informazioni commerciali devono avere per poter 
invocare la tutela. 


Costituiscono oggetto di tutela i segreti commerciali. Per segreti 
commerciali si intendono le informazioni aziendali e le esperienze 
tecnico-industriali, comprese quelle commerciali, soggette al 
legittimo controllo del detentore, ove tali informazioni: 


a) siano segrete, nel senso che non siano nel loro insieme o nella 
precisa configurazione e combinazione dei loro elementi 
generalmente note o facilmente accessibili agli esperti ed agli 
operatori del settore; 


b) abbiano valore economico in quanto segrete; 


c) siano sottoposte, da parte delle persone al cui legittimo controllo 

sono soggette, a misure da ritenersi ragionevolmente adeguate a 

mantenerle segrete. [...] 

La norma successiva invece, ai commi 1 e 1-bis, 
chiarisce la portata della tutela. 


1. Ferma la disciplina della concorrenza sleale, il legittimo detentore 
dei segreti commerciali [...] ha il diritto di vietare ai terzi, salvo 
proprio consenso, di acquisire, rivelare a terzi od utilizzare, in modo 
abusivo, tali segreti, salvo il caso in cui essi siano stati conseguiti in 
modo indipendente dal terzo. 


1-bis. L'acquisizione, l'utilizzazione o la rivelazione dei segreti 
commerciali [...] si considerano illecite anche quando il soggetto, al 
momento dell’'acquisizione, dell’utilizzazione o della rivelazione, era a 
conoscenza o, secondo le circostanze, avrebbe dovuto essere a 
conoscenza del fatto che i segreti commerciali erano stati ottenuti 
direttamente o indirettamente da un terzo che li utilizzava o rivelava 
illecitamente ai sensi del comma 1. 


L'acquisizione di software da 
parte della pubblica 
amministrazione 


Quando è una pubblica amministrazione (PA) a dover 
acquisire una soluzione software, lo scenario cambia in 
modo radicale, sia sul piano delle norme applicabili, sia 
sul piano dei modelli contrattuali. Si esce infatti dal 
mero campo d'azione della contrattazione privata e si 


entra nel campo d'azione più complesso dei contratti 
pubblici e dunque del diritto amministrativo. 
L'acquisizione di software da parte della PA è 
disciplinata dagli articoli 68 e 69 del Codice 
Amministrazione Digitale (CAD), oltre che dalle Linee 
guida su acquisizione e riuso di software per le 
pubbliche amministrazioni (documento disponibile 


maggio 2019), documento ufficiale dell'Agenzia per 
l’Italia Digitale (AgiD). 

Si tratta di un apparato normativo ispirato a un 
approccio di spending review ed efficientamento 
dell'azione amministrativa. Non a caso l'articolo 68 CAD 
stabilisce che le pubbliche amministrazioni, quando 
acquisiscono software, devono farlo nel rispetto dei 
principi di economicità e di efficienza, tutela degli 
investimenti, riuso e neutralità tecnologica. Inoltre la 
norma richiede che l'acquisizione avvenga a seguito di 
una valutazione comparativa di tipo tecnico ed 
economico tra le seguenti soluzioni disponibili sul 
mercato: 

a) software sviluppato per conto della pubblica amministrazione; 


b) riutilizzo di software o parti di esso sviluppati per conto della 
pubblica amministrazione; 


c) software libero o a codice sorgente aperto; 
d) software fruibile in modalità cloud computing; 
e) software di tipo proprietario mediante ricorso a licenza d’uso; 


f) software combinazione delle precedenti soluzioni. 


Si noti che queste sei opzioni non sono elencate in un 
ordine di priorità. Tuttavia il successivo comma 1-bis 
stabilisce: 


A tal fine, le pubbliche amministrazioni prima di procedere 
all'acquisto, devono effettuare una valutazione comparativa delle 
diverse soluzioni disponibili sulla base dei seguenti criteri: 


a) costo complessivo del programma o soluzione quale costo di 
acquisto, di implementazione, di mantenimento e supporto; 


b) livello di utilizzo di formati di dati e di interfacce di tipo aperto 
nonché di standard in grado di assicurare l’interoperabilità e la 
cooperazione applicativa tra i diversi sistemi informatici della 
pubblica amministrazione; 


c) garanzie del fornitore in materia di livelli di sicurezza, conformità 
alla normativa in materia di protezione dei dati personali, livelli di 
servizio tenuto conto della tipologia di software acquisito. 

E comunque l'acquisizione di programmi informatici di 
tipo proprietario può avvenire solo qualora dalla 
valutazione comparativa risulti motivatamente 
l'impossibilità di accedere a soluzioni già disponibili 
all’interno della pubblica amministrazione, o a software 
open source, adeguati alle esigenze da soddisfare 
(comma 1-ter). 

Tutte le indicazioni di carattere tecnico ed economico 
per effettuare nel modo corretto la valutazione 
comparativa sono riportate nelle già citate linee guida. 


Capitolo 4 


Il software libero e open 
source 


Le radici storiche 
dell’informatica e della 
cultura hacker 


Conoscere anche solo per sommi capi la storia 
dell'informatica ci aiuta a capire quale ruolo 
fondamentale ha avuto la cultura hacker nella spinta 
verso lo sviluppo e la divulgazione delle tecnologie 
digitali. 

NOTA 

Si legga a tal proposito l'ottima ricostruzione effettuata da Eric 

Raymond nel suo saggio “Breve storia sugli hacker”, che si trova 

anche nel libro Open Sources. Voci dalla rivoluzione Open Source, 

Apogeo, Milano, 1999. 

Anche se sappiamo che la scienza informatica ha 
radici ben più antiche (si pensi alla macchina di Turing 
risalente al periodo della seconda guerra mondiale), in 
questa sede possiamo iniziare la narrazione dal 1969, 
anno che rappresenta una indiscutibile pietra miliare del 
fenomeno. 

NOTA 


Uno dei primi calcolatori a transistor è il Tx-0, comparso nel 1959. E 
sempre nel 1959 ha inizio presso il MIT (Massachusetts Institute of 
Technology dell’Università di Cambridge, vicino a Boston) il primo 
corso di programmazione di computer. 

Fu in quel periodo che la prima ristretta comunità 
hacker venne portata dalla rivoluzione culturale in atto 
in quel periodo a uscire dal suo originario isolamento 
nelle università e nei centri di ricerca e ad affacciarsi al 
mondo reale. In quell’anno infatti vide la luce il sistema 
operativo Unix, grazie al lavoro di uno sviluppatore dei 
laboratori Bell: Ken Thompson, personaggio 
appartenente appunto a questa prima generazione di 
hacker. Unix era il primo sistema operativo sviluppato in 
linguaggio C (un particolare linguaggio di 
programmazione) e non in linguaggio macchina 
(binario) ed era il primo a realizzare l’idea di portabilità 
e compatibilità. Semplificando, ciò significa che prima di 
Unix ogni computer necessitava di un apposito sistema 
di software (sistema operativo + programmi vari); ogni 
volta che la macchina veniva aggiornata o sostituita era 
necessario riprogettare gran parte del sistema software. 
Grazie a Thompson invece il ruolo del software si fece 
più dinamico e gestibile con più facilità, al di là del 
supporto hardware su cui era installato; fu dunque 
possibile affacciarsi su un mercato dell'informatica 
decisamente più ampio ed elastico. 

Il 1969 è inoltre l’anno in cui furono collegati per via 
telematica i nodi dei centri di ricerca informatici di 
quattro grandi università statunitensi (Los Angeles, 
Santa Barbara, Stanford, Utah): nacque così ARPAnet, 


riconosciuta da tutti come l'effettivo embrione 
dell'Internet dei nostri tempi. 

NOTA 

Altri esempi di reti di connessione telematica erano già stati 

sperimentati e adottati all’epoca, però erano limitati a una funzione 

di intelligence militare. ARPAnet invece si avvicina di più a Internet 

per il suo spirito di fondo, ovvero la condivisione di informazioni. 

Si passa poi, con l’inizio degli anni Settanta, a una 
seconda generazione di hacker fedele ai principi etici 
originari, ma interessata più che altro alla diffusione del 
mezzo Su cui amavano operare. Il loro obiettivo era 
quello di fare uscire lo strumento “computer” dai grandi 
centri di ricerca, per renderlo più familiare alla grande 
massa degli utenti; si impegnavano affinché le 
apparecchiature fossero più piccole, maneggevoli ed 
economiche. In questo periodo apparvero i primi 
computer in kit di montaggio: apparecchi piuttosto 
spartani venduti a un prezzo base di 397 dollari e 
contenenti i primi processori Intel. È sempre in questo 
periodo che si cominciò a sentir parlare di Bill Gates, il 
quale ebbe il merito, assieme a Paul Allen, di aver 
utilizzato con successo il linguaggio Basic per rendere 
più semplice il funzionamento dei computer Altair. 

Nacque dunque nei primi anni Ottanta il concetto di 
personal computer, senza dubbio grazie all'impegno 
degli hacker nel “liberare l'hardware”, ma anche per 
semplici interessi economici da parte delle imprese che 
iniziarono a fiutare una nuova prospettiva di affari. La 
International Business Machine infatti mise sul mercato 
il suo primo computer da tavolo chiamato appunto IBM- 
PC - era dotato di un processore Intel 8088, di una 


memoria 16 K, di un lettore di cassette audio per 
memorizzare i dati (e non di un disco rigido) - e in 
contemporanea la stessa scelta di marketing venne 
compiuta dalla Apple e dalla Atari. IBM adotta all’inizio 
una politica aziendale piuttosto “illuminata”, cercando 
di incoraggiare la diffusione e lo sviluppo del software e 
stimolando la collaborazione di altre importanti imprese, 
come la Microsoft, che realizzò il sistema operativo per i 
nuovi computer: il sistema MS-DOS. 

In tal modo, quello strano aggeggio dotato di schermo 
e tastiera cominciava a fare capolino negli arredi delle 
case e degli uffici di tutto il mondo e in molti casi 
dovette “svilire” la sua funzione, essendo sfruttato come 
gioco e passatempo invece che come strumento di 
calcolo. Così una massa di persone inesperte si trovò a 
utilizzare giochi e software senza essere in grado di 
capire (0 senza nemmeno voler capire) di che cosa 
effettivamente si trattasse e di come fossero stati 
sviluppati, scegliendo i prodotti in base alla pubblicità o 
semplicemente affidandosi a pacchetti standard. 

Una conseguenza logica di questa espansione fu che 
più gli utenti divenivano numerosi e più questa terza 
generazione di hacker risultava frazionata e composita. 
Non solo lo zoccolo duro degli studiosi di informatica e di 
tecnologia, ma anche una sempre più numerosa schiera 
di curiosi, ai quali era però difficile trasmettere in modo 
completo e autentico certi principi etici nati in una sorta 
di ristretta casta. Si arrivò così a uno scenario 
abbastanza simile ai giorni nostri, in cui gli utenti si 
dividevano in varie macrocomunità rese compatte, più 


che dai principi etici, dagli usi che facevano del PC, e 
collegate dalla prima vera e propria Internet (come la si 
intende oggi). Arriviamo così alla seconda metà degli 
anni Novanta, periodo in cui - come vedremo - anche il 
fenomeno del software libero uscì dalla sua nicchia per 
affacciarsi al mondo del business (con la denominazione 
di “open source”). 


I lineamenti della cultura 
hacker 


Soffermiamoci ora sugli aspetti più rappresentativi 
dell'etica hacker fin qui solo accennati. È in effetti 
fondamentale capire come siano stati proprio questi 
principi filosofici a influire di più sulle nuove istanze in 
fatto di gestione del copyright sul software. | punti 
cardine di quella che sembra configurarsi come una 
“metasocietà” (nel senso di una società nella società) 
sono soprattutto i seguenti: 


e libertà di accesso alle risorse, siano esse intese come 
accesso alle informazioni, ai dati, oppure come 
accesso alle macchine e ai relativi componenti 
tecnologici necessari al loro miglior funzionamento; 

e condivisione delle conoscenze e degli strumenti; 

e cooperazione e unità nella realizzazione dei progetti 
utili alla comunità: infatti scismi, defezioni e 
biforcazioni in sottoprogetti vengono sempre visti di 
cattivo occhio e osteggiati; 

e semplificazione sia a livello tecnico sia a livello 
burocratico, che va di pari passo con ottimizzazione 


delle risorse (raggiungere il massimo risultato 
impiegando la soluzione più semplice e meno 
dispendiosa); 

e creatività: la progettazione, conoscenza (e in certi 
casi manomissione) dei sistemi informatici è 
considerata un'arte e quindi ogni operazione deve 
essere compiuta con stile e originalità; 

e onoree credibilità: tutti i cardini etici fin qui citati 
sono poi amalgamati da un grande senso dell'onore, 
della reputazione, della rispettabilità che pervadono 
la comunità hacker; le varie sottocomunità e i singoli 
progetti infatti hanno un loro leader, il quale si è 
guadagnato la credibilità con i meriti e l'anzianità; 
non mancano gli opinion leader, ovvero gli ideologi 
del movimento che si distinguono per carisma e 
capacità comunicativa e si fanno perciò portavoce 
della comunità e catalizzatori di attenzione. 


Una simile organizzazione non può che dotarsi di un 
proprio linguaggio originale formatosi con anni di 
strambe etimologie e distorsioni linguistiche (tratte il 
più delle volte da termini tecnici): uno slang 
caratteristico di matrice quasi del tutto “American- 
English” che si distingue per la sua insostituibile 
efficacia. Questo è il motivo per cui gran parte delle 
traduzioni in italiano si risolvono in tentativi piuttosto 
goffi che non rendono giustizia al reale significato dei 
termini. Lo stesso termine “hacker” non ha un 
corrispondente italiano; in ambito giornalistico si è 
diffusa la corrispondenza di “hacker” con “pirata 
informatico”, che però è del tutto impropria e semplifica 


in modo eccessivo il concetto (tra l’altro confondendolo 
con quello di “cracker”, che appunto è colui che viola e 
danneggia sistemi informatici). 


NOTA 

Riportiamo una curiosa e interessante ricostruzione dell’etimologia 
della radice hack-, tratta da uno dei libri fondamentali sul tema, ossia 
Hackers. Gli eroi della rivoluzione informatica, di Steven Levy 
(edizione originale del 1984; edizione italiana del 2002 per Shake 
Edizioni, Milano). A p. 23 dell'edizione italiana si legge: “I membri 
anziani stavano al club per ore, discutendo sul da farsi, sviluppando 
un gergo esclusivo, incomprensibile per gli estranei: un progetto 
intrapreso o un prodotto costruito non soltanto per adempiere a uno 
scopo specifico ma che portasse con sé il piacere scatenato della 
pura partecipazione, era detto ‘hack’. Quest'ultima parola proveniva 
dal vecchio gergo del MIT: il termine ‘hack’ era stato a lungo usato 
per indicare gli scherzi elaborati che gli studenti del MIT 
s'inventavano regolarmente”. Dunque un'impresa era definita vero 
hack se mostrava innovazione, stile e virtuosismo tecnico. Maggiori 
dettagli sull'opera: 
https://it.wikipedia.org/wiki/Hackers. Gli eroi della rivoluzione informati 





Un hacker è più che altro un esperto di informatica cui 
piace programmare, esplorare i sistemi informativi e le 
reti telematiche, mettere alla prova le architetture 
software e gli apparati di sicurezza informatica, e lo fa 
non con intenti di profitto ma per una sorta di 
irrefrenabile passione, quasi per vocazione. 


NOTA 

“[...] la programmazione per gli hacker è in primo luogo gratificazione 
dell’ego e solo a volte diventa, in aggiunta, leva di reddito. Allo 
stesso modo del canto o della pittura per gli artisti”. Cfr. Nicola Bassi, 
Open Source. Analisi di un movimento, Apogeo, Milano, 2000, p. 36, 
par. 2.2 (libro disponibile alla pagina web http://www. copyleft- 


italia.it/pubblicazioni). 


La nascita del movimento 
free software e del Progetto 
GNU 


Un sistema economico e giuridico nel quale il software 
era diventato un bene commerciale e proprietario, 
tutelato dai vincoli del copyright, non poteva essere 
tollerato da coloro che avevano fatto dello sviluppo di 
software una specie di missione intellettuale e che fino a 
quel momento erano abituati a considerare il software 
come qualcosa di liberamente osservabile, liberamente 
condivisibile e liberamente modificabile: appunto gli 
informatici delle prime generazioni, quelli cresciuti 
respirando la filosofia hacker che abbiamo illustrato 
poco sopra. Alcuni di essi, capitanati dal ricercatore del 
MIT Richard M. Stallman, pensarono che fosse necessario 
trovare un escamotage per continuare a condividere e a 
sviluppare senza vincoli il software come avevano fatto 
fino a quel Momento. Nacque così l’idea di free software 
(con free nel senso di “libero” e non di “gratuito”) e la 
soluzione del copyleft: un particolare meccanismo 
giuridico di inversione degli effetti del copyright, basato 
su licenze d'uso che, invece di limitare le possibilità di 
utilizzo delle opere, trasmettono una serie di libertà agli 
utenti. 

In sostanza, ciò che Stallman voleva era poter creare 
un modello di sviluppo software virtuoso e inclusivo, 
grazie al quale chiunque potesse contribuire al 
miglioramento dell’opera; e per farlo fece leva su due 
elementi fondamentali: un copyright più elastico con 


l'ideazione e diffusione della licenza capostipite del 
modello copyleft (la General Public License del Progetto 
GNU, o più in breve GNU GPL) e la disponibilità costante 
del codice sorgente. Nel 1983 avviò dunque il Progetto 
GNU, progetto tuttora attivo mirato appunto alla 
creazione di un sistema operativo del tutto libero, e nel 
1985 fondò la Free Software Foundation (FSF), l'ente 
non profit che si occupa della promozione di tale 
progetto e di tutti gli altri progetti coerenti con i principi 
del software libero. 

Da quel momento si iniziò a diffondere l’idea di libertà 
come un valore etico fondamentale per lo sviluppo di 
tecnologie informatiche: libertà dai vincoli giuridici della 
cosiddetta proprietà intellettuale (che abbiamo descritto 
sinteticamente nel paragrafo precedente), libertà dalle 
ottiche prettamente economiche che svilivano il 
software da oggetto di innovazione tecnologica a 
prodotto commerciale, libertà dalle valutazioni 
meramente strategiche delle aziende produttrici che 
andavano a scapito di una virtuosa condivisione delle 
conoscenze informatiche. 

Dagli anni Ottanta a oggi sono davvero numerosissime 
le iniziative che si muovono nel solco tracciato con il 
Progetto GNU. Ed è grazie a questa idea rivoluzionaria 
che, con il prezioso contributo di Linus Torvalds 
(informatico finlandese che nel 1991 ha creato il kernel 
Linux), oggi possiamo disporre di sistemi operativi 
(definiti appunto sistemi GNU/Linux) solidi, affidabili e 
del tutto liberi, nonché di innumerevoli applicativi 


sviluppati secondo lo stesso modello e con la stessa 
filosofia di fondo. 


Le quattro libertà del 
software libero 


Come abbiamo già spiegato, la distribuzione del 
software in formato binario senza la disponibilità del 
relativo codice sorgente è stata fin dagli anni Ottanta 
una delle principali strategie applicate dalle software 
house per mantenere maggior controllo sulla 
circolazione delle proprie opere e sull'eventuale 
riproduzione e imitazione da parte di concorrenti. 
Questa scelta è in palese contrasto con i principi del 
software libero, perché di fatto, dal punto di vista di 
Stallman e soci, va a inficiare tutte le libertà 
fondamentali degli utenti di software. 

Infatti secondo la Definizione di Software Libero, testo 
manifesto del Progetto GNU, sono quattro le libertà 
fondamentali che devono essere sempre garantite 
affinché si possa parlare in modo legittimo di “software 
libero”. 


NOTA 

In nota nel documento si legge: “Il motivo per cui la numerazione è 
0, 1, 2,3 è storico: intorno al 1990 c'erano tre libertà numerate 1, 2, 
3; poi abbiamo capito che la libertà di eseguire il programma per 
qualsiasi scopo doveva essere citata esplicitamente, ed essendo più 
fondamentale delle altre tre, le doveva precedere, da cui la 
numerazione ‘0’ per evitare di cambiare il numero delle altre”. Cfr. 
secondo i termini della licenza Creative Commons Attribuzione - Non 
opere derivate 4.0 Internazionale (CC BY-ND 4.0). 


Un programma è software libero se gli utenti del programma godono 
delle quattro libertà fondamentali: 

- Libertà di eseguire il programma come si desidera, per qualsiasi 
scopo (libertà 0). 

- Libertà di studiare come funziona il programma e di modificarlo in 
modo da adattarlo alle proprie necessità (libertà 1). L'accesso al 
codice sorgente ne è un prerequisito. 

- Libertà di ridistribuire copie in modo da aiutare gli altri (libertà 2). 

- Libertà di migliorare il programma e distribuirne pubblicamente i 
miglioramenti da voi apportati (e le vostre versioni modificate in 
genere), in modo tale che tutta la comunità ne tragga beneficio 
(libertà 3). L'accesso al codice sorgente ne è un prerequisito. 

Un programma è software libero se l'utente ha tutte queste libertà in 
modo adeguato. Altrimenti diciamo che è non libero. | modelli di 
distribuzione non liberi si possono differenziare a seconda di quanto 
si distanziano dall'essere liberi, ma per noi sono tutti non etici allo 
stesso modo. 


Emerge con chiarezza quanto sia centrale la 
disponibilità del codice sorgente per la piena 
realizzazione delle libertà numero 1 e 3 (libertà di fare 
modifiche e di pubblicare versioni modificate) e dunque 
l'accessibilità al codice sorgente è una condizione 
essenziale e necessaria per il software libero. 

A proposito di queste due libertà, infatti, il documento 
prosegue così. 

Il “codice sorgente” deliberatamente offuscato non è vero codice 


sorgente e non può essere considerato tale. 


La libertà 1 comprende la libertà di utilizzare una versione da voi 
modificata anziché l'originale. Se il programma è distribuito in un 
prodotto che, per scelta progettuale, esegue le versioni modificate da 
una specifica persona o azienda ma si rifiuta di eseguire quelle 
modificate da voi (tecnica nota come “tivoization” o come “lockdown” 
o come “secure boot” secondo la discutibile definizione che ne danno 
i suoi sostenitori), allora la libertà 1 diventa una richiesta vuota senza 
alcun valore concreto. La versione eseguibile di questi programmi 


non è software libero anche se il codice sorgente da cui sono stati 
ottenuti è libero. 


Un importante modo di modificare un programma è quello di 
includervi funzioni e moduli liberi già esistenti. Se la licenza del 
programma prevede che non si possano includere moduli già 
esistenti (nonostante abbiano una licenza appropriata), ad esempio 
se richiede che voi possiate aggiungere solo codice di cui detenete il 
copyright, allora la licenza è troppo restrittiva per essere considerata 
libera. 


Il concetto di “open source” 
e la Open Source Definition 


A metà degli anni Novanta si aprì un dibattito su come 
rendere più appetibile alle imprese dell'ICT (e quindi non 
più solo alla comunità degli hacker) lo sviluppo di 
software in uno spirito per l'appunto libero dalle barriere 
di natura tecnica e giuridica che abbiamo illustrato. 
Alcuni attivisti del settore proposero una nuova 
definizione per il fenomeno che potesse porre l'accento 
non tanto sull'aspetto etico della libertà quanto 
sull'aspetto più tecnico della disponibilità e apertura del 
codice sorgente (detto in inglese “source code” 0 
semplicemente “source”). 

Si iniziò così a parlare di “open source” e tale termine - 
pur osteggiato dai puristi - ebbe un notevole successo 
grazie alla sua particolare efficacia comunicativa. 
Superata la fase della scelta terminologica, bisognava 
redigere le linee guida di questa nuova realtà. Uno dei 
suoi massimi fautori, Bruce Perens, si preoccupò di 
redigere la Open Source Definition (OSD), una sorta di 


“decalogo” di riferimento per chiarire a priori che cosa 
potesse essere ricondotto al concetto di open source. 
La differenza tra l'operato della Free Software 
Foundation (FSF) e quello della Open Source Initiative 
(OSI) sta più che altro nell'approccio. La prima ha creato 
una licenza di riferimento (la GPL) e invita gli 
sviluppatori a utilizzare quella per essere sicuri di 
muoversi in coerenza con i principi del software libero; 
in alternativa FSF consente l'utilizzo di altre licenze 
considerate compatibili con la GPL. La seconda, invece, 
procede in senso inverso, riconoscendo ex post la 
qualifica di “open source” a tutti i progetti (e quindi a 
tutte le licenze) che risultino coerenti con i parametri 
indicati nella Open Source Definition (Figura 4.1). 


open source 
Initiative 
Approved License? 








Figura 4.1 Il logo che indica una licenza formalmente approvata dalla 
Open Source Initiative. 


Tuttavia, dal punto di vista della sostanza, molti 
osservatori hanno fatto notare che in realtà le due 
“scuole di pensiero” non fanno altro che utilizzare due 
nomi per un unico grande fenomeno. Non a caso da un 
po’ di tempo si sente parlare in senso generico di FOSS 
(o a volte FLOSS), un acronimo un po' cacofonico che 
però ha il merito di comprendere tutte le varie accezioni 
del fenomeno: significa infatti Free (Libre) and Open 
Source Software ed è utilizzato da tutti quegli studiosi 
che intendono trattare il tema senza dover ogni volta 
effettuare fastidiose precisazioni terminologiche. 

Non vi è dubbio che l'aggettivo “open” ha riscosso un 
successo indiscutibile e infatti, al di là delle valutazioni 
terminologiche (e a volte ideologiche) interne al 
movimento, è ormai dato storico che tale aggettivo 
abbia visto allargare negli ultimi anni il suo ambito 
semantico fino ad altri campi non solo informatici e che 
sia stato utilizzato per individuare un movimento 
culturale, un nuovo approccio, per certi versi addirittura 
una filosofia. L'openness appunto. 


La soluzione del rilascio in 
pubblico dominio 


Una persona poco consapevole delle dinamiche dello 
sviluppo di software potrebbe pensare che, se 
l'intenzione è quella di diffondere software con la 
massima libertà, è sufficiente lasciarlo del tutto fuori dal 


campo d'azione del copyright, dicendo che non c'è 
alcun diritto su quell’opera. Basterebbe quindi 
diffondere il proprio software corredandolo di codice 
sorgente e dichiarandolo fin da subito in pubblico 
dominio, senza dover attendere che trascorra il lungo 
periodo di settant'anni dalla morte dell'autore previsto 
dalla legge. È un’opzione praticabile nel mondo 
statunitense dove, come abbiamo spiegato, gli autori 
non mantengono un legame indissolubile con le proprie 
opere attraverso i cosiddetti diritti morali. In sostanza è 
sufficiente distribuire l’opera accompagnandola non con 
una licenza libera, bensì con una dichiarazione di 
rilascio in pubblico dominio: una sorta di disclaimer in 
cui si segnala che l’autore dell’opera ha deciso di 
rinunciare all'esercizio dei suoi diritti sull'opera e che 
quindi preferisce donarla come patrimonio 
creativo/culturale dell'umanità. lo lo chiamo “pubblico 
dominio artificiale”, in contrapposizione con il pubblico 
dominio naturale che avviene quando invece sono 
trascorsi i famosi settant'anni. 

Però c'è un però; e non è una questione da poco. 

Rilasciare il software in pubblico dominio significa 
donarlo all'umanità, lasciarlo circolare senza alcun 
vincolo, farlo diventare di tutti e di nessuno. Da un 
punto di vista filosofico potrebbe sembrare una scelta 
molto open; solo che, come abbiamo visto, uno dei 
fattori fondanti per la libertà del software è che sia 
sempre corredato dal suo codice sorgente. Se Tizio 
rilascia un pacchetto software munito di codice sorgente 
in un regime di pubblico dominio perde tutti i diritti su 


di esso, tra cui anche quello di chiedere che il codice 
sorgente venga sempre reso disponibile. Caio dunque 
potrà prendere quel software, farci qualche modifica, 
rilasciarlo come opera derivata chiudendo il codice 
sorgente. Gli utenti del software rilasciato da Caio non 
potranno più accedere al codice sorgente del software 
derivato, e nemmeno al codice rilasciato da Tizio, che 
rappresenta la parte più cospicua dell’opera derivata. Ed 
ecco che le libertà concesse da Tizio vengono subito 
vanificate e il suo approccio “open” cade presto 
nell'oblio. 


Le licenze permissive 


Una soluzione leggermente diversa dal rilascio in 
pubblico dominio è quella rappresentata dalle 
cosiddette licenze permissive, ossia delle licenze molto 
lasse che in sostanza permettono di fare qualsiasi cosa 
con il software licenziato e, in caso di realizzazione di 
opere derivate, impongono solo la condizione di 
menzionare l’autore dell’opera originaria. A differenza 
della soluzione del rilascio in pubblico dominio, il titolare 
dei diritti non rinuncia alle sue prerogative e mantiene 
quindi un ruolo di licenziante. In sostanza, facendo 
riferimento al set di licenze proposte da Creative 
Commons, le licenze permissive equivalgono a una 
semplice Attribution. Il loro senso si può condensare 
nella frase: “Fai pure quello che vuoi della mia opera 
(anche opere derivate e anche a scopi commerciali), 
basta che mi citi sempre come autore originario”. 


Tra queste licenze possiamo citarne un paio molto 
note, che prendono il nome dalle due grandi istituzioni 
universitarie americane che le hanno create e utilizzate 
per prime: la BSD License (il cui acronimo sta per 
Berkeley Standard Distribution) lanciata dall'Università 
di Berkeley in California; e la MIT License, lanciata dal 
Massachusetts Institute of Technology di Boston. 
Trattandosi di grandi centri di ricerca pubblici il loro 
scopo era quello di rilasciare il software nel modo più 
semplice possibile e di assicurarsi solo un 
riconoscimento “morale” alla paternità scientifica 
dell’opera. 

Oltre a queste di matrice accademica, ne sono poi 
comparse altre provenienti dal settore business, come 
per esempio la Apple Public Source License e la Apache 
License. 

Si tratta senza dubbio di licenze molto semplici, lineari 
e di facile comprensione; tuttavia il problema della 
chiusura del codice sorgente che si pone a proposito del 
pubblico dominio si pone anche con queste licenze. Se 
l’unica clausola è quella del riconoscimento della 
paternità, chiunque potrà fare opere derivate e 
diffonderle chiudendo il codice sorgente. 


Le licenze di copyleft forte e 
la GPL come licenza 
capostipite 


Se le soluzioni fin qui presentate si sono rivelate 
inefficaci a innescare il meccanismo virtuoso del 


software libero con le sue quattro libertà, c'era bisogno 
di qualcosa di diverso: serviva una licenza che 
preservasse quelle libertà e che in sostanza sfruttasse il 
copyright per mantenere libero il software. 

Sembra un paradossale gioco di parole, ma è in realtà 
il geniale “uovo di Colombo” escogitato alla fine degli 
anni Ottanta da Richard M. Stallman (fondatore del 
Progetto GNU e della Free Software Foundation) con 
l'assistenza di Eben Moglen (avvocato e docente di 
diritto della proprietà intellettuale): lo strumento della 
licenza d'uso, ben noto al mondo della distribuzione di 
software, poteva essere utilizzato non solo per limitare 
gli utilizzi del software (com'era stato fino a quel 
momento) ma anche per garantire una serie di diritti e di 
libertà agli utenti, e per far sì che tali libertà 
persistessero anche nella diffusione di opere derivate, 
mantenendo sempre la disponibilità del codice sorgente 
grazie alla clausola “copyleft”. In quest'ottica la licenza 
non è più solo un lungo elenco di regole e condizioni 
imposte agli utenti; ma, riprendendo una celebre frase 
attribuita allo stesso Moglen, la licenza diventa “la 
costituzione di una community”. 

Il risultato è in concreto questo: Tizio rilascia un 
software con licenza copyleft; Caio utilizza quel codice 
per realizzare un software derivato e decide di 
distribuire il software derivato; Caio è obbligato ad 
applicare la stessa identica licenza anche al software 
derivato; se Caio non ottempera a questa condizione 
indicata nella licenza, compie una violazione del 
copyright di Tizio e quest'ultimo può fargli causa. Come 


possiamo vedere, quindi, il copyright diventa lo 
strumento giuridico non più per “chiudere” l’opera ma 
per mantenerla aperta, anche in futuro e con un effetto 
“a cascata” anche sulle opere derivate dalle derivate (e 
così via). 

Il meccanismo del copyleft fin dagli albori è sempre 
stato rappresentato con il simbolo del copyright (la C 
cerchiata ©) capovolto sottosopra, con un intento 
goliardico che indica un capovolgimento e anche una 
beffa del copyright tradizionale. Quel simbolo è stato poi 
ripreso anche dalle licenze Creative Commons nell’icona 
che rappresenta la clausola “Share Alike” (letteralmente: 
condividi allo stesso modo), cioè la clausola che nel 
mondo Creative Commons individua lo stesso concetto: 
appunto quello di mantenere sulle opere derivate la 
stessa licenza dell’opera originaria. Nella grafica di 
Creative Commons la C rovesciata ha la forma di una 
freccia (si veda la Figura 4.2) e comunica con efficacia il 
senso di un ritorno: il licenziante dà delle libertà ai 
licenziatari e chiede che anche i licenziatari diano le 
stesse libertà agli altri, e quindi in modo indiretto anche 
al licenziante originario. 


Figura 4.2 A sinistra il simbolo del copyleft; a destra il simbolo della 
clausola Share Alike di Creative Commons. 


La licenza GPL 

Nacque così nel 1989 la General Public License del 
Progetto GNU (anche nota come GNU GPL, o 
semplicemente GPL), la licenza capostipite di questo 
nuovo approccio alla distribuzione di software. La GPL 
incarna il modello di licenza copyleft per eccellenza, nel 
senso più classico, come concepito e voluto dai fondatori 
del movimento del software libero. Oltre a essere una 
licenza è anche una sorta di manifesto del movimento, 
con un ampio preambolo di natura più etico-filosofica 
che giuridica (caratteristica che attirò alcune critiche dal 
mondo dei giuristi), nel quale vengono estrinsecati | 
principi del movimento. 

La GPL è persistente e propagativa, e queste due 
caratteristiche la classificano come licenza di copyleft 
forte. 

Come spiega efficacemente Wikipedia (cfr. 
luglio 2020), la GPL è classificabile come: 


- persistente perché impone un vincolo alla redistribuzione: se 
l'utente distribuisce copie del software, deve farlo secondo i termini 
della GPL stessa. In pratica, deve distribuire il testo della GPL assieme 
al software e corredarlo del codice sorgente o di istruzioni per poterlo 
ottenere ad un costo nominale. [...] L'effetto che realizza è 
mantenere libero un programma una volta che esso è stato posto 
sotto GPL, anche se viene migliorato correggendolo e ampliandolo 
Eiwedi 


- propagativa [o come alcuni dicono impropriamente, virale] perché 
definisce nel testo una particolare interpretazione di “codice 
derivato”, tale che in generale l'unione di un programma coperto da 
GPL con un altro programma coperto da altra licenza può essere 
distribuita sotto GPL, o in alternativa non essere distribuita affatto. 
Nel primo caso si dice che l’altra licenza è “compatibile con la GPL; 
nel secondo caso che non lo è. Lo scopo [di questa caratteristica] è 
evitare che la persistenza venga via via indebolita apportando 
modifiche coperte da un’altra licenza meno libera, inficiando così lo 
scopo di mantenere libero il software coperto dalla GPL. 
La GPL non è l’unica licenza di copyleft forte esistente; 
anzi, come vedremo, c'è una tendenza a una 
proliferazione eccessiva di licenze che in alcuni casi 


rappresentano dei veri doppioni. 


Le varie versioni della GPL e le 


altre licenze di copyleft forte 

Abbiamo detto che la licenza GPL arrivò nel 1989; 
tuttavia già nel 1991 fu pubblicata una sua seconda 
versione che poi divenne la licenza copyleft più diffusa 
in assoluto per quasi vent'anni. Basti pensare che il 
kernel Linux fu rilasciato nel 1991 proprio sotto questa 
licenza; e tuttora la licenza non è stata cambiata. 

Nel 2007 la Free Software Foundation ha pubblicato la 
versione 3 della GPL, che mostra sostanziali differenze 
con la precedente versione. Oltre a una riorganizzazione 
strutturale del testo e a una maggiore chiarezza 
terminologica, la terza versione cerca di risolvere alcuni 
problemi che la precedente non aveva considerato e che 
erano emersi nei primi anni Duemila esponendo la 
licenza a un suo “indebolimento”. Come spiega Brett 
Smith nella sua “Guida rapida alla GPLv3” 


(https ://ww.gnu.org/licenses/quick-guide-gplv3.html; a rticolo rilasciato 


sotto licenza Creative Commons BY-ND 3.0), la terza 
versione cerca di limitare tre “nuovi” problemi. 


Tivoizzazione: alcune società hanno creato diversi tipi di dispositivi 
che eseguono software con licenza GPL, ma hanno manipolato 
l'hardware per fare in modo che solo loro possano modificare il 
software installato, non voi. Se un dispositivo può eseguire software 
arbitrario si tratta di un vero e proprio computer e il suo proprietario 
deve avere il controllo su ciò che fa o non fa. Quando un dispositivo 
ve lo impedisce ci riferiamo ad esso con il termine “tivoizzazione”. 


Leggi che proibiscono il software libero: Legislazioni tipo il Digital 
Millennium Copyright Act e l’European Union Copyright Directive 
rendono penalmente perseguibile scrivere o condividere software in 
grado di infrangere un DRM (che per noi significa “gestione digitale 
delle restrizioni”). Queste leggi non devono interferire con i diritti che 
la GPL vi garantisce. 


Accordi discriminatori di brevetto: Microsoft ha recentemente iniziato 

a dire alle persone che non citeranno in giudizio gli utenti del 

software libero per infrazione dei brevetti di licenza, a patto che 

ottengano il software da un fornitore che paga a Microsoft questo 
privilegio. In sostanza, Microsoft sta cercando di riscuotere i diritti 
d'autore per l’impiego del software libero, il che interferisce con la 

libertà degli utenti. Nessuna società dovrebbe essere in grado di 

comportarsi così. 

Si noti che, a rigore, la versione 3 è incompatibile con 
la versione 2, a meno che il licenziante abbia 
espressamente precisato “o qualsiasi versione 
successiva” (cosiddetta “clausola di aggiornamento”). 

Altra licenza di copyleft forte è la European Union 
Public License (EUPL), una licenza redatta dalle 
istituzioni dell'Unione Europea e destinata alla 
distribuzione di software sviluppato nell’ambito dei 
programmi IDA (Interchange of Data between 
Administrations, cioè scambio elettronico di dati fra 


amministrazioni) e IDABC (Interoperable Delivery of 
European eGovernment Services to public 
Administrations, Businesses and Citizens, cioè fornitura 
interoperabile di servizi amministrativi online europei 
alle pubbliche amministrazioni, alle aziende e ai 
cittadini). Ma comunque, come spiegava il sito di IDABC 
in una pagina non più online, “il testo della Licenza è 
redatto in termini generali, quindi la licenza può essere 
utilizzata per altre applicazioni software, a seconda dei 
casi, da altre Istituzioni europee, da amministrazioni 
nazionali, regionali o locali, altri enti pubblici e privati 
entità e persone fisiche”. La licenza, pubblicata nel 
2007, ha in realtà riscosso molto meno successo rispetto 
alle aspettative. Ma per fortuna, spiega Carlo Piana, “la 
EUPL contiene una clausola di compatibilità che 
consente di utilizzare, per le opere derivate, una lista di 
altre licenze, tra le quali la GNU GPL, per cui le 
conseguenze dannose sono in via pratica evitate” (Carlo 
Piana, Open source, software libero e altre libertà. 
Un'’introduzione alle libertà digitali, Ledizioni, Milano, 
2018, p. 42). 

Per chi volesse leggere il testo della licenza (che in 
appendice riporta anche la lista delle licenze dichiarate 
“compatibili”), la sua traduzione italiana ufficiale è 


La Affero GPL e il copyleft di rete 

Come abbiamo spiegato, l’effetto copyleft della GPL si 
innesca con la distribuzione dell’opera derivata. Che 
cosa succede però se il software non viene realmente 


distribuito, ma viene reso fruibile in Rete su un server 
(cosiddetto “cloud computing”)? D'altronde il mercato 
del software sta andando proprio in quella direzione e 
dunque l'efficacia della GPL rischierebbe di uscirne 
ridotta se non addirittura vanificata. Come sottolinea 
l'apposita voce di Wikipedia, “seppure la lettera della 
GNU GPL non venga violata, ne viene violato lo spirito in 
quanto ci si avvale di materiale soggetto a copyright di 
altri senza rendere alla comunità le modifiche 
effettuate”. Serve dunque una licenza che tra le 
condizioni d’uso imposte agli utilizzatori preveda quella 
di distribuire il codice anche nel caso in cui i programmi 
girano su un computer remoto e non vengono realmente 
distribuiti in copie. 

Il problema era già stato sollevato durante il periodo di 
redazione e discussione della GPLv3 e si era anche 
prospettata l'ipotesi di risolverlo inserendo una specifica 
clausola nel testo della licenza. Si decise però di 
mantenere la GPLv3 più “neutra” e di redigere 
un'apposita licenza per il software reso fruibile via Rete. 

Venne così alla luce la GNU Affero GPL (o anche AGPL), 
licenza che prende il nome da una piccola società di 
servizi web che per prima aveva sollevato la questione e 
che già nel 2002 aveva pubblicato una versione iniziale 
della licenza. La AGPL è stata poi fatta propria dalla Free 
Software Foundation e pubblicata nel 2007, in sintesi 
modificando il testo della GPLv3 e aggiungendovi una 
clausola specifica (la numero 13) intitolata “Remote 
Network Interaction; Use with the GNU General Public 
License”. 


Tale clausola descrive una condizione d'uso aggiuntiva 
rispetto alla GPL classica: se in un server viene eseguito 
un programma modificato e si permette che gli utenti 
comunichino con esso, il server deve anche consentire 
agli utenti di scaricare il codice sorgente della versione 
modificata in questione. 

Per la sua chiarezza, torna utile riportare la 
spiegazione fornita dal sito del Progetto GNU 
nell'articolo divulgativo “I motivi della GNU Affero GPL” 


(https://ww.gnu.org/licenses/why-affero-gpl.it.html): 


Lo scopo della GNU Affero GPL è di prevenire un tipico problema che 
affligge gli sviluppatori di programmi liberi utilizzati nei server. 


Supponiamo che voi sviluppiate e rilasciate un programma libero 
sotto normale licenza GNU GPL. Se lo sviluppatore D modifica il 
programma e lo rilascia, la GPL lo obbliga a distribuire sotto la 
medesima licenza GPL anche la sua versione modificata. In tal modo, 
se vi procurate una copia della sua versione, siete liberi di 
implementare alcune o tutte le sue modifiche nella vostra versione 
personale. 


Supponiamo però per un attimo che il programma in questione sia 
utile principalmente nei server. Quando D modifica il programma, egli 
potrebbe con tutta probabilità eseguirlo nel suo server personale 
senza mai rilasciarne una copia. In tal caso voi non otterreste mai il 
codice sorgente della sua versione, motivo per cui non avreste mai la 
possibilità di includere le sue modifiche nella vostra versione. L'esito 
derivante da tale circostanza potrebbe non piacervi affatto. L'utilizzo 
della GNU Affero GPL previene tale situazione spiacevole. 


La AGPL, in quanto licenza nata da una costola della 
GPLv3, risulta compatibile con quest'ultima, ma non con 
le precedenti versioni della GPL. 


Le licenze di copyleft debole 


Fin dai primi anni di vita della GPL da più parti si fece 
notare che in alcune specifiche situazioni la clausola 
copyleft risulta troppo rigida, con l’effetto di 
disincentivare l'utilizzo di software libero a favore di 
soluzioni proprietarie. È il caso di tutti i software che per 
loro natura sono “ancillari” verso altri software, come per 
esempio le librerie di funzioni. Questi software nascono 
non tanto per avere una “vita autonoma” quanto per 
essere utilizzati da altri software e in essi incorporati. Un 
approccio fortemente “propagativo” come quello della 
GPLe delle altre licenze copyleft obbligherebbe quindi 
gli sviluppatori che incorporano nel loro nuovo software 
una libreria di funzioni rilasciata sotto GPL a rilasciare 
tutto il loro codice con licenza GPL. Visto che però non 
tutti gli sviluppatori di software (o le software house) 
sono disposti a farlo, l’effetto collaterale sarebbe quello 
che tutti i produttori di software proprietario non 
sceglierebbero mai librerie sotto licenza GPL e dunque le 
librerie “open source” verrebbero fortemente 
penalizzate. 

Per superare questo impasse, il Progetto GNU decise di 
redigere una licenza in cui l’effetto copyleft è attenuato; 
ed è per questo che si parla di “copyleft debole”. 

In sostanza, le licenze di questo tipo non fanno 
scattare il copyleft in caso venga inserita o strettamente 
collegata una libreria (o altro software “ancillare”) a un 
software più ampio. 

La prima licenza di questa famiglia è la Lesser General 
Public License (cioè GPL “minore”), o anche Library 
General Public License (cioè GPL per librerie), abbreviata 


comunque in LGPL. Nacque nel 1991 e nel 2007 è 
arrivata alla sua versione 3 seguendo in sostanza 
l'evoluzione della sua “sorella maggiore”. 

Per comprenderne meglio lo spirito, leggiamo un 
estratto del preambolo alla versione 2 (in traduzione 
italiana non ufficiale). 


La GPL Attenuata (LGPL) è assai diversa dalla GPL normale e viene 
usata per determinate librerie in modo da permettere il collegamento 
di tali librerie a programmi non liberi. 


Quando un programma è collegato con una libreria, sia staticamente 
sia usando una, libreria condivisa, legalmente parlando, la 
combinazione dei due elementi è un’opera derivata della libreria 
originale. Perciò la normale GPL permette tale collegamento solo se 
l’intera combinazione risulta conforme ai propri criteri di libertà. La 
GPL Attenuata consente criteri più permissivi per collegare altro 
codice alla libreria. 


Ora che abbiamo messo a fuoco il meccanismo che ha 
portato a redigere questa licenza, si tenga presente che 
la Free Software Foundation tiene a sottolineare che 
l'utilizzo di questa licenza dev'essere considerato solo 
come soluzione straordinaria, riservata a quei casi in cui 
appunto l'utilizzo della GPL risulti controproducente. 
Basta proseguire nella lettura del preambolo. 


Questa licenza viene definita GPL Attenuata perché fa meno per 
proteggere la libertà dell'utente rispetto alla normale GPL. Essa 
fornisce inoltre minori vantaggi agli sviluppatori di software libero 
nella competizione con programmi non liberi. Questi svantaggi sono 
la ragione per cui usiamo la GPL per molte librerie. Tuttavia, la GPL 
Attenuata fornisce dei vantaggi per certe circostanze speciali. 


Ad esempio, in rare occasioni, può presentarsi la necessità particolare 
di incoraggiare l’uso più ampio possibile di una determinata libreria, 
in modo che divenga uno standard de facto. Per raggiungere 
quest’obiettivo, i programmi non liberi devono essere in grado di 
utilizzare la libreria. Il caso più frequente è quello di una libreria libera 


che svolga lo stesso compito di una libreria non libera largamente 
utilizzata. 


In questa situazione, ha poco senso limitare la libreria libera a 
interagire solo con software libero, quindi utilizziamo la GPL 
Attenuata. 

Altra nota licenza di copyleft debole è la Mozilla Public 
License (MPL), utilizzata per il codice della Mozilla 
Application Suite, di Mozilla Firefox, di Mozilla 
Thunderbird e di altri prodotti Mozilla. La licenza è stata 
pubblicata nel 2012 e a oggi è arrivata alla sua versione 
2.0. 
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Figura 4.3 Classificazione delle licenze free software/open source. 


Free Software Foundation e 
Open Source Initiative: i due 
diversi approcci alle licenze e 

il problema dell’eccessiva 
proliferazione 


In questo capitolo abbiamo menzionato più volte due 
enti che a livello internazionale indirizzano e presidiano 


lo sviluppo di software libero con codice sorgente 
aperto: la Free Software Foundation e la Open Source 
Initiative. Senza dilungarci in disquisizioni sulla storia 
dei due enti e sulla loro impostazione “filosofica”, ai fini 
della nostra analisi è però utile mettere in luce i due 
diversi approcci alla questione delle licenze. 

Da un lato abbiamo la Free Software Foundation (FSF), 
organizzazione non profit fondata nel 1985 dallo stesso 
Richard M. Stallman, che applica un approccio più 
“purista” e indica nella licenza GNU GPL il modello di 
licenza per antonomasia, da utilizzare il più possibile. 
Ogni altra licenza viene considerata subottimale, come 
d'altronde abbiamo già visto poco sopra commentando 
le indicazioni fornite sull'utilizzo della LGPL. Ciò 
nonostante FSF redige e aggiorna periodicamente una 
software libero, cioè di tutte le licenze che garantiscono 
le famose quattro libertà fondamentali, che sono 
suddivise in licenze software libero compatibili con la 
GPL (che alla data di redazione del presente libro 
ammontano a cinquantaquattro) e licenze software 
libero incompatibili con la GPL (che alla data di 
redazione del presente libro ammontano a quarantatré), 
per un totale di quasi un centinaio, in cui sono incluse 
però anche le diverse versioni delle varie licenze. 

La Open Source Initiative (OSI), ente di cui abbiamo 
già raccontato brevemente la storia, applica un 
approccio diverso. In un documento chiamato Open 
Source Definition (a sua volta derivato dalle preesistenti 
Debian Free Software Guidelines) ha indicato quali sono 


le caratteristiche che una licenza deve avere per poter 
essere considerata open source (secondo il senso di 
“open source” inteso dalla OSI). Questo approccio fa Sì 
che in sostanza qualsiasi ente, azienda, progetto possa 
redigere una propria licenza e richiedere l'aggiunta alla 
lista delle licenze OSI. 

Al momento della redazione del presente libro, la lista 


sito di OSI prevede un totale di novantatré licenze, tra 
cui vi sono cinque licenze che vengono indicate come 
non più utilizzate poiché “volontariamente ritirate” da 
parte dei loro promotori e altre dodici che vengono 
considerate “superate” da versioni più recenti. 

Come è possibile notare anche senza essere esperti di 
licensing, entrambe le liste di licenze curate da FSF e 
OSI sono eccessivamente lunghe, atteso che le 
macrocategorie di licenze sono più o meno sempre le tre 
che abbiamo illustrato (permissive, copyleft forte, 
copyleft debole). Una comparazione tra le due liste è 
disponibile su Wikipedia in questa pagina: 
poi pensiamo che Creative Commons, ente che propone 
licenze rivolte a tutti i tipi di opere dell'ingegno (escluso 
il software), è riuscita a limitare il set di licenze a sei 
diverse declinazioni, questi numeri che si avvicinano al 
centinaio danno ancora più nell'occhio. 

Da tempo si stigmatizza questa proliferazione di 
licenze (“license proliferation”), poiché una 
sovrabbondanza di licenze non fa altro che aumentare il 
livello di incertezza tra gli utenti, i quali si trovano a 


doversi interrogare sulle implicazioni giuridiche delle 
varie licenze e della compatibilità tra esse, dunque a 
dover gestire molte più incognite e criticità di carattere 
legale. Unica categoria che ne esce avvantaggiata è 
quella (cui appartengo) dei legali che si occupano di 
consulenza sul diritto della proprietà intellettuale, che 
ricevono più incarichi professionali proprio per dipanare 
dubbi di interpretazione e di compatibilità. 

Nello stesso tempo, non si può nemmeno vietare che 
un nuovo progetto di sviluppo di software open source 
preferisca non adottare una licenza preesistente e 
quindi scriverne una da zero, per poi sottoporla al vaglio 
dei due enti che abbiamo citato. 

Proprio su questo tema la stessa OSI ha promosso uno 
studio condotto da un comitato di giuristi specializzati 
che ha prodotto un interessante report in cui si mettono 
in luce i tre punti dolenti della license proliferation: 

a) Troppe licenze diverse rendono difficile per i licenziatari scegliere 

Alcune persone usano l’espressione “license proliferation” per 

indicare che ci sono troppe licenze e che qualcuno deve prendere 

delle misure per ridurre il numero. Anche se questo sarebbe 
fantastico, l'’OSI non può indurre nessuno ad usare o non usare una 


particolare licenza. Tutto ciò che possiamo fare è educare e sollecitare 
le persone a utilizzare un sottoinsieme di licenze più ristretto. [...] 


b) Alcune licenze non funzionano bene insieme 


Alcune persone utilizzano l’espressione “license proliferation” per 
riferirsi al fatto che alcune licenze open source non interagiscono 
bene con altre licenze open source. Sebbene possiamo sollecitare le 
persone a non mescolare licenze non mescolabili, non possiamo 
impedire alle persone di farlo. [...] 


c) Troppe licenze rendono difficile capire cosa stai accettando in una 
distribuzione multi-licenza 


Questo è correlato all'argomento precedente, ma è leggermente 
diverso visto che non ci si lamenta di come interagiscono le licenze; 
si segnala solo che ci sono troppe diverse licenze individuali che 
coprono determinate distribuzioni e che ci vuole molto tempo per 
leggerle e comprenderle tutte. [...] 


Compatibilità tra licenze 
open source 


Già leggendo questi ultimi paragrafi si sarà percepito 
che uno dei temi chiave in materia di software libero e 
open source è quello della compatibilità tra le licenze. 
D'altronde lo scopo del movimento del free software è 
proprio la creazione di un ecosistema di progetti e 
community di sviluppo software che per vocazione 
prendono codice preesistente e lo riutilizzano o lo 
miscelano con altro codice per tirare fuori soluzioni 
software nuove. Se Tizio prende il codice di Caio 
rilasciato sotto la licenza Alfa e vuole farne un’opera 
derivata, dovrà solo rispettare le condizioni di 
quell’unica licenza. Se invece Tizio vuole realizzare 
un'opera derivata prendendo un po' di codice di Caio 
rilasciato sotto la licenza Alfa e un po' di codice di 
Sempronio rilasciato sotto la licenza Beta, deve 
preoccuparsi che le licenze Alfa e Beta siano tra esse 
compatibili e permettano a Tizio di fare quel mash up di 
software. 

Come vedremo più avanti anche nel campo dei dati, le 
licenze di copyleft forte creano più problemi di 
compatibilità per una questione più logica che giuridica: 
infatti, dal momento che richiedono di mantenere la 


stessa licenza anche sulle opere derivate, non 
consentono margini di scelta a Tizio (autore dell’opera 
derivata). Se la licenza Alfa dice “ogni opera derivata 
dovrà essere rilasciata con questa stessa licenza” e la 
licenza Beta dice la stessa identica cosa, ci crea un 
conflitto perché non si riesce a definire quale delle due 
prevarrà; e Tizio sarà costretto a violare le condizioni di 
almeno una delle due. 

Cambiamo scenario e ipotizziamo invece che la 
licenza Alfa sia una licenza “permissiva” (semplice 
“attribution”), che dice unicamente “ogni opera derivata 
dovrà riportare la menzione dell'autore originario”, e che 
la licenza Beta sia una licenza di copyleft forte. Tizio 
dunque potrà miscelare i due codici e rilasciare l’opera 
derivata applicandovi la licenza Beta e aggiungendo 
una menzione dell'autore originario nella nota con i 
credits. In questo modo le condizioni di entrambe le 
licenze saranno rispettate. 

La questione della compatibilità è molto più 
complessa ed è altamente dipendente 
dall’interpretazione delle varie clausole delle licenze. 
D'altronde, come già spiegato poco sopra a proposito 
della license proliferation, la continua diffusione di 
licenze diverse (che però in realtà sono riconducibili alle 
solite macrocategorie) rischia di aumentare le incertezze 
e le incognite anche in ottica di compatibilità. 

Per agevolare la comprensione del tema e fornire delle 
linee guida relative almeno alle licenze più diffuse e più 
note, la Free Software Foundation ha diffuso schemi e 
indicazioni operative, tra cui un articolo dello stesso 


Stallman intitolato “La compatibilità tra le licenze e il re- 
licenziamento”. L'articolo è disponibile in traduzione 
Sullo stesso argomento si legga anche “Guida rapida 
alla GPLv3” di Brett Smith disponibile all'indirizzo 


Network 
Protective 





Figura 4.4 Un noto diagramma che rappresenta il rapporto di compatibilità 
tra le principali licenze free software/open source. Si noti che la direzione 
delle frecce ha uno specifico significato, dato che la compatibilità può 
variare proprio a seconda della direzione (si parla appunto di compatibilità 
in entrata, in-bound, e di compatibilità in uscita, out-bound). Il diagramma 
è disponibile su Wikimedia Commons 

(https://en.wikipedia.org/wiki/License compatibility#/media/File:Floss- 


ShareAlike 3.0 unported ed è stato realizzato nel 2007 da David A. Wheeler 
per l'articolo “The Free-Libre/Open Source Software (FLOSS) License Slide”. 


Il meccanismo del dual 
licensing (o multilicensing) 


Quello del dual licensing è uno dei meccanismi più 
utilizzati nei modelli di business basati su software open 


source, proprio perché permette di contemperare la 
filosofia della condivisione del codice in modalità open e 
l'esigenza, in alcuni casi imprescindibile, di aderire a un 
approccio proprietario. 

La soluzione del dual licensing (letteralmente “duplice 
licenziamento”) diventa strategica tutte quelle volte in 
cui un'azienda vuole utilizzare del codice sorgente 
rilasciato sotto una licenza copyleft ma non vuole, o non 
può a causa di vincoli pregressi, aderire al cosiddetto 
“share alike”; cioè non vuole o non può condividere il 
suo codice sorgente. 

Spieghiamolo meglio. L'azienda Alfa sviluppa 
l'applicazione X e la rilascia con una licenza copyleft 
mettendo a disposizione anche il relativo codice 
sorgente; l'azienda Beta sta sviluppando un più ampio 
progetto Y in cui potrebbe risultare particolarmente utile 
incorporare il codice dell’applicazione X. Tuttavia questo 
progetto più ampio dovrà essere rilasciato con una 
licenza proprietaria e dunque per Beta non è possibile 
rilasciare tutto il codice sorgente del progetto in 
modalità open come invece richiederebbe la licenza 
dell’applicazione X. Allora Beta decide di contattare 
l'azienda Alfa e le chiede una licenza specifica che le 
permetta di utilizzare il codice dell’applicazione X senza 
però l'obbligo di rilasciare tutto il codice del progetto Y. 
Alfa accetta e, dietro versamento di un compenso una 
tantum o di una royalty a percentuale, concede questa 
licenza. 

In questo senso quindi si può parlare di dual licensing. 
Da un lato, infatti, l'azienda Alfa rilascia lo stesso 


identico codice con due diverse licenze: una licenza 
open source copyleft rivolta al pubblico e gratuita e una 
licenza commerciale e a pagamento rivolta a coloro che 
hanno particolari esigenze. E, come anticipato all’inizio 
di questo paragrafo, grazie a questo meccanismo Alfa 
riesce ad aumentare i suoi introiti legati al codice 
sorgente sviluppato per l'applicazione X; ma a sua volta 
Beta riesce a portare avanti il progetto Y pagando il 
giusto e senza dover riscrivere ex novo una consistente 
parte di codice. 

A volte le licenze con cui viene offerto il software 
possono essere anche più di due, a seconda dei vari 
scenari e delle varie esigenze contingenti. Non a caso 
alcuni parlano di “multilicensing” (si veda per esempio 
https://en.wikipedia.org/wiki/Multi-licensing) € non strettamente di 


“dual licensing”. 


Capitolo 5 


La proprietà intellettuale 
sui dati 


NOTA 

II contenuto di questo capitolo riprende e aggiorna quanto già 
pubblicato nell'articolo “Open licensing e banche dati”, uscito sulla 
rivista Informatica e diritto (XXXVII Annata, Vol. XX, n. 1-2, 2011, pp. 
25-43); e in seguito nel libro // fenomeno open data. Indicazioni e 
norme per un mondo di dati aperti (Ledizioni/Copyleft-Italia.it, Milano, 
2014). 


Dati in che senso? 


Il linguaggio di norma usato in campo informatico 
spesso induce a creare confusione sul reale significato di 
“dati”. C'è infatti la tendenza a parlare in senso generico 
di “dati” in riferimento a tutto il materiale 
memorizzabile su un supporto di memoria, 
indipendentemente che si tratti di film, brani musicali, 
documenti, immagini, file di altro tipo. In senso ancora 
più ampio e neutro il vocabolario online Treccani fornisce 
una definizione alquanto efficace: “Ciò che è 
immediatamente presente alla conoscenza, prima di 
ogni forma di elaborazione” (cfr. 


riporta anche: “Con uso più generico, elemento, in 


quanto offerto o acquisito o risultante da indagini e 
utilizzato a determinati scopi”). 

Tuttavia, dal punto di vista del linguaggio giuridico (di 
cui è necessario tenere conto in una riflessione come 
questa) “dati” ha una portata semantica più ristretta e si 
riferisce appunto solo alle singole e isolate informazioni, 
non organizzate e non elaborate dall’ingegno umano. 
Queste, in quanto singole informazioni deducibili dalla 
natura delle cose, non sono sottoposte ad alcuna tutela 
e privativa diretta. Dunque la proprietà intellettuale non 
si occupa tanto di dati quanto di banche dati (o di 
database nell'accezione inglese), ed è molto importante 
tenere sempre presente questa distinzione. 

Per definire in poche parole che cosa sia una banca 
dati (o database), possiamo dire che è un insieme 
organizzato e strutturato di dati. Un'altra definizione 
può tornare utile, ovvero quella di database che si trova 
sull’Enciclopedia Treccani online: “Espressione nata 
nell’ambito dell'informatica gestionale per indicare un 
insieme organizzato di informazioni di tipologia 
differente, ordinato secondo criteri che permettono 
l'inserimento, l'elaborazione, la manutenzione e la 
ricerca delle informazioni stesse, sia nelle loro forme 
elementari più semplici sia in forme aggregate più 


Anche se quest’ultima è una definizione rivolta al 
mondo informatico più che giuridico, è sufficiente a darci 
conferma che “dati” e “banca dati” sono effettivamente 
due concetti non sovrapponibili. Di conseguenza 


possiamo affermare che i “dati” sono oggetto di 
regolamentazione e tutela da parte del diritto della 
proprietà intellettuale solo quando si presentano come 
sistemi organizzati. 

Come vedremo più avanti, in Europa, con l'avvento 
negli anni Novanta di una normativa ad hoc, il concetto 
di database è stato ulteriormente precisato e 
approfondito da parte della scienza giuridica. A tal 
proposito si veda la definizione fornita all'articolo 1.2 
dalla direttiva n. 96/9/CE, che diventerà da qui in poi il 
principale riferimento per la nostra analisi: 


Ai fini della presente direttiva per “banca di dati” si intende una 

raccolta di opere, dati o altri elementi indipendenti sistematicamente 

o metodicamente disposti ed individualmente accessibili grazie a 

mezzi elettronici o in altro modo. 

Non è casuale che l'esigenza di interrogarsi 
sull'opportunità di un particolare trattamento legale per 
i database sia emersa solo negli ultimi decenni; ciò è 
appunto del tutto connesso alle nuove possibilità di 
raccolta, organizzazione e fruizione di grandi quantità di 
dati derivanti dalle tecnologie digitali e alle opportunità 
commerciali basate su questo tipo di attività. Ciò 
nonostante, come si può notare, la definizione fa 
riferimento anche a banche dati consultate in modo non 
digitale; quindi sono ricompresi anche classici esempi di 
banche dati analogiche come l'elenco telefonico o gli 
archivi e le biblioteche. 

Infine un'ultima precisazione: a volte emerge la 
tendenza a confondere la banca dati con il software che 
la gestisce. Molti informatici dicendo “database” 
indicano un tutt'uno che comprende sia il software sia i 


dati sottostanti, mentre utilizzano “dataset” per indicare 
la massa di dati in senso più stretto. In effetti spesso si 
tratta di due rovesci della stessa medaglia, di due 
componenti difficilmente separabili. Tuttavia, da un 
punto di vista giuridico, è fondamentale non sovrapporre 
i due concetti: un conto è il software (nel senso di 
codice), che è tutelato secondo quanto abbiamo 
spiegato nel dettaglio nei capitoli precedenti; altro conto 
sono i dati che tale software raccoglie e organizza. In un 
mondo ideale di applicativi software rigorosamente 
progettati secondo standard aperti e interoperabili, la 
stessa massa di dati dovrebbe essere gestibile con 
facilità da applicativi diversi e quindi le due realtà 
(software e banca dati) essere del tutto indipendenti. 
Ciò, appunto, avviene solo in un mondo ideale; ma non è 
detto che sia una prospettiva del tutto utopistica. 


dato vs informazione 


—» 1225 
—» metri 


informazione 
—» altitudine 


—» Bormio 





Figura 5.1 Un'infografica molto semplice che spiega il rapporto tra il 
concetto di dato e il concetto di informazione. Il dato è quell’elemento 
“granulare” che rischia di non avere un significato univoco e definito senza 
una contestualizzazione; per estrarre informazione da una banca dati è 
spesso necessario l'incrocio e il collegamento di più dati granulari e in 


alcuni casi di metadati (a ben vedere, “altitudine” e “metri” potrebbero 
essere considerati in questo caso più dei metadati). 


La tutela delle banche dati 
prima del 1996 


La tutela delle banche dati rappresenta uno dei risvolti 
più complessi del diritto della proprietà intellettuale 
nonché uno degli aspetti di maggior disallineamento tra 
il sistema giuridico americano e quello europeo. Nel 
1996 infatti una direttiva della Comunità Europea ha 
introdotto un particolare tipo di diritto non assimilabile 
né al concetto di copyright né a quello di diritto 
d'autore, e proprio per questo denominato dalla dottrina 
“diritto sui generis”. Tale diritto crea particolari problemi 
di gestione ed enforcement e permette agli operatori 
europei di vantare una tutela più forte sulle banche dati 
(e di riflesso quindi anche sui dati in esse contenuti) 
rispetto agli operatori statunitensi. 

Da ciò deriva anche il fatto che il dibattito sulle 
licenze open per dati ha avuto origine ed è stato più 
sentito in Europa rispetto ad altri Paesi. 

La banca dati può essere in un certo senso equiparata 
alle opere collettive, categoria già nota al diritto 
d'autore prima ancora delle riforme degli anni Novanta. 
In generale, infatti, la Convenzione di Berna e tutte le 
normative nazionali a essa ispirate includono fra le 
tipologie di opere tutelate dal nostro ordinamento anche 
quelle realizzate attraverso la raccolta di altre opere 
autonome dall'opera collettiva. 


Questo è infatti il testo dell'articolo 2(5) della 
Convenzione di Berna: 


Le raccolte di opere letterarie o artistiche come le enciclopedie e le 
antologie che, per la scelta o la disposizione della materia, abbiano 
carattere di creazioni intellettuali sono protette come tali, senza 
pregiudizio del diritto d'autore su ciascuna delle opere che fanno 
parte delle raccolte stesse. 


NOTA 


anche l'articolo 5 del WIPO Copyright Treaty del 1996: “Compilations 
of Data (Databases) - Compilations of data or other material, in any 
form, which by reason of the selection or arrangement of their 
contents constitute intellectual creations, are protected as such. This 
protection does not extend to the data or the material itself and is 
without prejudice to any copyright subsisting in the data or material 
contained in the compilation”. 

[“Raccolta di Dati (Banca dati) - Le raccolte di dati o di altro materiale, 
in ogni forma, che per la selezione o la disposizione dei loro contenuti 
costituiscono creazioni intellettuali, sono protette in quanto tali. 
Questa protezione non si estende ai dati o al materiale stesso e lascia 
impregiudicati i diritti d'autore che sussistono sui dati o sul materiale 
contenuto nella raccolta”.] 


Colui che effettua la selezione, la raccolta e la 
disposizione secondo specifici criteri creativi detiene 
quindi un diritto d'autore a sé stante rispetto a quello 
delle singole opere raccolte. 

Con l'avvento delle nuove modalità di memorizzazione 
e di gestione tecnologica delle informazioni, i database 
sono diventati una parte fondamentale dell'attività di 
produzione culturale e tecnica. Dunque il mondo del 
diritto ha iniziato a interrogarsi se fosse necessario 
prevedere specifiche forme di tutela di questa nuova 
categoria di creazioni, o se al contrario fosse sufficiente 


applicarvi (in maniera estensiva) le categorie e i principi 
già esistenti nel diritto d'autore. 


Se il diritto d’autore classico 
si rivela inadeguato per le 
banche dati 


Già da una prima lettura della norma si può afferrare 
che la definizione di opere collettive (nel senso di 
collezioni di opere) si riferisce a fenomeni non sempre 
equiparabili a una banca dati. Non tutte le banche dati 
possiedono il requisito della scelta e della disposizione 
del materiale secondo criteri creativi; “non in particolare 
quelle che, proponendosi di fornire tutte le informazioni 
disponibili su un dato argomento, non attuano alcuna 
selezione e che presentano le informazioni stesse 
secondo un ordine banale o imposto da esigenze 
informative” (Paolo Auteri, “Diritto d'autore”, in Paolo 
Auteri, Giorgio Floridia, Vito Maria Mangini e altri, Diritto 
industriale. Proprietà intellettuale e concorrenza, 
Giappichelli, Torino, 2005, parte VI, pp. 505-508). 

Inoltre esiste un altro “tallone di Achille” del diritto 
d'autore nella sua applicazione a opere atipiche come le 
banche dati: il principio per cui il diritto d'autore copre 
solo la forma espressiva di un'opera, cioè il modo con cui 
l’autore ha espresso la sua idea e non l’idea in sé. Perciò, 
soprattutto in questo caso, sulla base del solo diritto 
d'autore un altro soggetto potrebbe utilizzare i contenuti 
della banca dati modificandone il criterio di disposizione 
e organizzazione, realizzando a tutti gli effetti un’opera 


diversa dal punto di vista giuridico, ma ripetitiva e 
“parassitaria” nella sostanza. 

Con la sola applicazione del diritto d'autore un’ampia 
fetta di banche dati resterebbe priva di tutela giuridica; 
rimarrebbe solo la tutela derivante dai principi della 
concorrenza sleale o l'eventuale applicazione di sistemi 
tecnologici di protezione. Ciò è stato considerato 
insufficiente da parte del legislatore comunitario, il 
quale, dopo un acceso dibattito sull'opportunità di 
questa scelta, ha deciso di attivarsi con un'apposita 
direttiva. 

Tale scelta è stata sostenuta dall'idea secondo cui certi 
tipi di banche dati, che per loro natura sarebbero escluse 
dal campo d'azione del diritto d'autore, richiedono 
comunque un grande investimento da parte di soggetti 
specializzati e quindi questo investimento rimane di per 
sé meritevole di essere tutelato e, di conseguenza, 
incentivato. 


NOTA 

Si leggano a tal proposito i Considerando 7 e 12 della direttiva: “(7) 
considerando che per poter creare una banca di dati è necessario 
investire considerevoli risorse umane, tecniche e finanziarie, mentre 
è possibile copiarle o accedervi ad un costo molto più basso rispetto 
a quello richiesto per crearle autonomamente; (12) considerando che 
tale investimento nei moderni sistemi di memorizzazione e gestione 
delle informazioni non sarà effettuato all’interno della Comunità a 
meno che non venga introdotta una tutela giuridica stabile ed 
uniforme per tutelare i costitutori di banche di dati”. 


Un duplice livello di tutela: la 
direttiva del 1996 e Il diritto 


sui generis 


Dunque il legislatore europeo nel 1996 ha deciso di 
delineare un particolare sistema secondo il quale le 
banche dati sono sottoposte a un duplice livello di 
tutela. Con la direttiva n. 96/9/EC, da un lato le banche 
dati sono state in senso formale inserite tra le categorie 
di opere dell'ingegno tutelate da diritto d'autore 
previste dalla normativa comunitaria; dall'altro lato, 
sono stati creati appositi diritti per il costitutore della 
banca dati priva di carattere creativo. 


NOTA 

“Questo carattere può essere ricercato alternativamente o 

cumulativamente nella scelta o nella disposizione dei materiali” (Luigi 

Carlo Ubertazzi, a cura di, “Diritto d’autore”, estratto da 

Commentario breve alle leggi su proprietà intellettuale e concorrenza, 

Cedam, Padova, 2009, IV ed., p. 185). 

Come fa notare Paolo Auteri “la prima tutela [cioè il 
copyright] ha ad oggetto la ‘forma espressiva’ e cioè il 
modo in cui il materiale informativo è selezionato e 
disposto; la seconda invece ha ad oggetto il contenuto 
informativo, o meglio l'insieme delle informazioni nella 
misura in cui la ricerca, la verifica e la presentazione 
abbia richiesto un investimento rilevante” (Auteri, 
“Diritto d'autore”, op. cit.). 

Il testo della direttiva consta di sedici articoli suddivisi 
in quattro Capitoli. Il Capitolo Il è dedicato appunto alla 
protezione delle banche dati intese come creazione 
dell'ingegno propria del loro autore e da tutelare quindi 
con copyright. Fin qui la direttiva non fa altro che 
chiarire e sancire formalmente ciò che era già deducibile 
dai principi del copyright. 


NOTA 

Articolo 3.1: “A norma della presente direttiva, le banche di dati che 

per la scelta o la disposizione del materiale costituiscono una 

creazione dell'ingegno propria del loro autore sono tutelate in quanto 
tali dal diritto d'autore. Per stabilire se alle banche dati possa essere 
riconosciuta tale tutela non si applicano altri criteri”, 

La parte davvero innovativa (e anche la più criticata) 
della direttiva è invece il Capitolo III, nel quale vengono 
istituiti nuovi diritti per la tutela delle banche dati prive 
di carattere creativo e quindi non considerate a pieno 
titolo opere dell'ingegno. Tali nuovi diritti (in genere 
denominati al singolare con la locuzione latina “diritto 
sui generis”, proprio a indicare la loro peculiarità 
rispetto ai diritti d'autore e ai diritti connessi) sono diritti 
esclusivi che sorgono in capo a un soggetto definito 
dalla norma “costitutore della banca dati”, si riferiscono 
all'investimento sostenuto per la realizzazione del 
database (e non all'apporto creativo come nel caso dei 
diritti d'autore e dei diritti connessi) e durano quindici 
anni dalla costituzione della banca dati. 


NOTA 

Per la precisione, l'articolo 10.1 della direttiva recita: “Il diritto di cui 

all'articolo 7 produce i propri effetti non appena completata la 

costituzione della banca di dati. Esso si estingue trascorsi quindici 

anni dal 1° gennaio dell’anno successivo alla data del 

completamento”. 

| principi della direttiva sono poi stati recepiti dagli 
Stati membri della UE e sono divenuti parte integrante 
nelle normative nazionali, rendendo così l'assetto 
normativo di tutta l'Unione Europea abbastanza 
uniforme. 


Nel Capitolo Ill dedicato al diritto su/ generis sono 
descritte due fondamentali attività di competenza del 
“costitutore” e sulle quali appunto vengono esercitati 
questi diritti: l'estrazione dei dati dal database (intesa 
come “il trasferimento permanente o temporaneo della 
totalità o di una parte sostanziale del contenuto di una 
banca di dati su un altro supporto con qualsiasi forma di 
messa a disposizione del pubblico della totalità o di una 
parte sostanziale del contenuto della banca di dati 
mediante distribuzione di copie, noleggio, trasmissione 
in linea o in altre forme”; si veda articolo 7 “Oggetto 
della tutela”). 

In altri termini, il costitutore ha il diritto esclusivo di 
controllare per quindici anni queste attività sul database 
(o su una sua parte sostanziale) da lui realizzato e 
messo a disposizione del pubblico. Ciò - appunto - 
avviene anche quando si tratti di un database senza 
carattere creativo, ma che abbia comunque richiesto un 
investimento rilevante sotto il profilo qualitativo o 
quantitativo. 

Come rappresentato nel box seguente quando 
abbiamo a che fare con banche dati, dobbiamo 
considerare questi due livelli di tutela e valutare se si 
tratti di un database con carattere creativo, nel qual 
caso avremmo entrambi i livelli di tutela; o se si tratti di 
un database senza carattere creativo, nel qual caso 
avremmo solo la tutela del diritto sui generis. 





Il diritto sui generis in sintesi 


e Oggetto del diritto + qualsiasi banca dati anche priva di carattere 
creativo che abbia richiesto un rilevante investimento per la sua 
costituzione. 


e Titolare del diritto -+ soggetto che ha effettuato il rilevante 
investimento (“costitutore”). 

e Effetto del diritto + vengono riservate al titolare le attività di 
estrazione e reimpiego di parti sostanziali della banca dati. 

e Durata del diritto + quindici anni dalla messa in commercio della 
banca dati. 





Diversi livelli di tutela per 
diverse tipologie di database 


Per effetto dei principi posti dalla direttiva e quindi dei 
diversi casi di sovrapposizione fra i due livelli di tutela, 
possiamo delineare queste tipologie di database tutelati 
dalla normativa europea. 





Tipo 1. Database con carattere creativo contenente opere 
creative 

Esempio: una banca dati di fotografie organizzata da un esperto di 
fotografia che struttura i contenuti secondo particolari criteri, relativi 
allo stile dei fotografi, alle tecniche fotografiche utilizzate, ai soggetti 
ritratti. 

Questo database è protetto da copyright su due livelli indipendenti: 
l’autore del database detiene i diritti d'autore in merito alla sua 
strutturazione e alla particolare organizzazione dei contenuti; inoltre gli 
autori dei singoli contenuti (le fotografie) detengono il diritto d'autore 
sui singoli contenuti in modo del tutto indipendente. L'autore del 
database infatti, per poterlo pubblicare, dovrà essersi premurato di 
ottenere dai fotografi le necessarie autorizzazioni e licenze. 

Nello stesso tempo il database è tutelato anche da diritto sui generis, 
poiché l’autore ha sostenuto un rilevante investimento nella 
realizzazione dell'opera e dunque ha la possibilità di vietare attività di 
estrazione e riutilizzo di parti sostanziali del database, anche quando 
queste parti non coinvolgono le opere creative contenute (per esempio 
i metadati delle fotografie). 

Tipo 2. Database con carattere creativo contenente semplici 

dati 


Esempio: una banca dati per il calcolo del rischio sismico che contiene 
semplici dati come le coordinate geografiche, le tipologie di terreno, le 
percentuali di rischio sismico, i dati storici degli eventi sismici; e in cui 
tali dati sono organizzati e disposti secondo criteri molto complessi e 
risultanti da scelte intellettuali specifiche da parte degli autori della 
banca dati. 

Tale database è protetto su due livelli diversi (il diritto d'autore e il 
diritto sui generis) e l’autore del database detiene i diritti d'autore in 
merito alla sua strutturazione e alla particolare organizzazione dei 
contenuti; lo stesso autore veste anche il ruolo di costitutore e detiene 
quindi anche il diritto sui generis per quanto riguarda l'estrazione e il 
reimpiego di parti sostanziali del database. 

Tipo 3. Database senza carattere creativo contenente semplici 
dati, ma che comunque ha richiesto un investimento rilevante 
Esempio: raccolta di tutti gli orari dei bus delle compagnie private 
locali; oppure il catalogo di un archivio in cui i documenti sono 
organizzati per data o in ordine alfabetico. 

Questi database non denotano alcun carattere creativo perché i criteri 
di organizzazione dei dati non richiedono una scelta intellettuale 
apprezzabile e sono invece “criteri necessitati” spesso generati con 
procedimenti automatici (ordine alfabetico, ordine numerico). Inoltre il 
loro contenuto è di dati “semplici” e non di opere creative (come 
invece avviene nel Tipo 1). Nella maggior parte dei casi, i database di 
questo tipo possono essere semplificati fino a diventare un file in 
formato CSV. 

Essi sono quindi tutelati solo dal diritto sui generis e il loro costitutore 
(parlare di “autore” non sarebbe appropriato) può controllare e vietare 
le attività di estrazione e reimpiego di parti sostanziali di dati. 





Da questa schematizzazione si coglie quanto sia 
importante aver sempre ben presenti i due livelli di 
tutela, in particolare quando ci si deve occupare del 
licenziamento di un database. Dovremo quindi avere le 
idee molto chiare su quali diritti e quali oggetti 
intendiamo licenziare; nello stesso tempo dovremo 
cercare di comunicare con la massima chiarezza le 
nostre intenzioni ai licenziatari, specificando 


espressamente se ci stiamo riferendo al database in sé, 
ai suoi contenuti, o a entrambi. 

Il fattore determinante per la suddivisione in queste 
tre tipologie è - come spesso accade nel diritto d'autore - 
la presenza del carattere creativo (Figura 5.2). Come 
spiega Luigi Carlo Ubertazzi nel suo Commentario breve 
(Commentario breve alle leggi su Proprietà Intellettuale 
e Concorrenza, estratto “Diritto d'autore”, 4a edizione, 
CEDAM, 2009), la creatività in senso generale “è intesa 
come capacità dell’opera di costituire espressione della 
personalità del suo autore”; e più specificamente 
nell’ambito delle banche dati il carattere creativo può 
essere ricercato “alternativamente o cumulativamente 
nella scelta o nella disposizione dei materiali”. 


banche dati: diversi livelli di tutela 


livello diritto 
sui generis 


informazioni, _- i. i ae 
non raccolti in sis) di 
un database 
nessuna tutela 


solo diritto diritto sui generis 
sui generis + diritto d'autore 





Figura 5.2 | due diversi livelli di tutela per le banche dati basati sul 
requisito del carattere creativo. 


Ancora più precisamente si esprime Paolo Spada 
(Banche di dati e diritto d’autore (il “genere” del diritto 
d'autore sulle banche di dati), in AIDA 1997, Giuffrè, 
1998), secondo il quale: 


il termine “disposizione” corrisponde a quelli di “coordination” e 
“arrangement” della tradizione giuridica statunitense; questi ultimi a 
loro volta corrispondono rispettivamente alla “integrazione dei dati in 
un reticolo di collegamenti” e all’“ordine sequenziale dei dati” 
(alfanumerico, tematico, categorico, geografico, cronologico ecc.). 


I concetti di “derivazione” e 
“Integrazione” nel mondo 
delle banche dati 


Buona parte dei problemi in tema di licenziamento e 
riutilizzo di dati deriva dalle clausole che 
limitano/condizionano l’attività di realizzazione di 
database “derivati” (ne parleremo meglio quando 
tratteremo licenze come la Open Database License e le 
Creative Commons con clausola share alike). 

Il concetto di “opera derivata” proviene infatti dal 
diritto d'autore classico, cioè il diritto d'autore applicato 
alle opere creative in senso pieno: tipici esempi di opere 
derivate sono la traduzione di un testo letterario, il 
remix di un brano musicale, l'adattamento 
cinematografico di un’opera teatrale. La realizzazione di 
una banca dati “nuova” partendo da una banca dati 
preesistente comporta un'attività diversa, che quindi, 
per essere correttamente inquadrata dal punto di vista 
giuridico, necessita di essere definita in Modo molto 
preciso a livello contrattuale (appunto nelle licenze 
d'uso applicate). 

Al contrario di quanto accade con le opere 
dell'ingegno tutelate dal diritto d'autore (comprese le 
banche dati con carattere creativo), per le quali si parla 


spesso di “derivazioni”, “elaborazioni creative” e “opere 
derivate”, non è chiaro se si possa applicare la categoria 
della derivazione ai database tutelati da mero diritto SU/ 
generis. Ciò è dovuto al fatto che tra i diritti esclusivi del 
costitutore di banca dati non vengono annoverati i diritti 
relativi alle classiche forme di derivazione e 
rielaborazione (come per esempio la traduzione, il 
riassunto, l'adattamento ad altro media, il 
riarrangiamento musicale); bensì, più propriamente, 
viene annoverato solo un diritto di impedire attività di 
estrazione e reimpiego di dati dal database (perla 
precisione di parti sostanziali del database). 

Dobbiamo poi mettere a fuoco il concetto di 
integrazione tra database poiché in effetti “integrare” 
un database non creativo all’interno di un altro database 
non creativo è un’operazione diversa rispetto 
all'integrazione di due testi letterari o di due pacchetti 
software. Si tratta in sostanza di riversare i dati di un 
database all’interno di un altro autonomo database, 
rendendo le due masse di dati non più distinguibili, e 
lasciare che poi il database risultante venga diffuso, 
utilizzato, consultato come un “tutt'uno”. Ma non si ha 
una vera e propria “contaminazione” stilistica e creativa 
come appunto avviene con altri tipi di opere. 

Non a caso, nel mondo dei database non creativi 
rilasciati, a volte il problema della compatibilità tra 
licenze si risolve tenendo i dataset separati e facendo in 
modo che l'utilizzatore possa interrogarli attraverso 
un'unica interfaccia software (realizzando così quella 


che nell’ambito software abbiamo chiamato “mera 
aggregazione”). 

Per fare un esempio in metafora, integrare due dataset 
differenti è come miscelare due diversi tipi di cereali: da 
un lato abbiamo la confezione di fiocchi d'avena, 
dall'altro la confezione di riso soffiato, e li versiamo 
entrambi in un unico contenitore. Otteniamo così un mix 
che contiene sia fiocchi d'avena sia riso soffiato dal 
quale è difficile e poco pratico dividere di nuovo i due 
tipi cereali. Scriveremo sul contenitore “mix di fiocchi 
d'avena e riso soffiato”, che, seguendo sempre il senso 
della metafora, corrisponde alla classica avvertenza con 
i credits in cui indichiamo le due diverse fonti dei dati 
che sono state integrate in questo nuovo dataset 
derivato. Se però per qualche ragione contingente 
abbiamo necessità di poterli sempre separare anche a 
posteriori (per esempio, nostro figlio è intollerante ai 
fiocchi d'avena), non possiamo far altro che avere un 
contenitore che comunque abbia al suo interno due 
vaschette separate in cui da una parte possiamo mettere 
i fiocchi d’avena e dall'altra il riso soffiato. All'atto 
pratico, quando vorremo versare i cereali nella scodella, 
potremo comunque versarli insieme mescolandoli nella 
scodella; ma quando invece dovremo preparare la 
colazione per nostro figlio, potremo prendere solo i 
cereali dalla vaschetta del riso soffiato. 

Uscendo dalla metafora, l'intolleranza di nostro figlio, 
che appunto ci obbliga a tenere separati i cereali anche 
se vengono conservati in un unico contenitore, 
corrisponde a una questione di incompatibilità tra i due 


database; incompatibilità che potrà essere derivante 
dalle rispettive licenze oppure dalla natura non 
omogenea dei dati. 


Scenari più frequenti di 
integrazione e derivazione 
tra banche dati 


Integrazione di dataset 


preesistenti 

Come primo scenario poniamo quello in cui Tizio 
realizza il Dataset A con il numero dei casi di morbillo 
registrati nel 2015 in tutti i comuni della Provincia 
Autonoma di Bolzano. Caio realizza un autonomo 
Dataset B il numero dei casi di morbillo registrati nello 
stesso anno nei comuni della Provincia Autonoma di 
Trento. Sempronio vuole realizzare un Dataset C con il 
numero di tutti i casi registrati nel 2015 nella Regione 
Trentino-Alto Adige suddivisi per comuni e dunque può 
farlo semplicemente aggregando Dataset A e Dataset B 
in un più ampio Dataset C. In Dataset C i dati vengono 
riorganizzati secondo un criterio diverso. | due dataset 
originari perdono quindi i loro “confini” e si fondono in 
un nuovo e autonomo dataset. 

Questa attività di integrazione fa sì che il Dataset C 
debba essere considerato come un dataset derivato 
contemporaneamente da Dataset A e da Dataset B. Di 
conseguenza Sempronio dovrà ottenere il permesso per 


l’attività di integrazione sia da Tizio sia da Caio; oppure, 
qualora i due dataset originari siano rilasciati con una 
licenza pubblica, dovrà verificare se le due licenze 
consentono quella specifica attività e se sono tra esse 
compatibili. Sempronio dovrà infatti rispettare sia le 
condizioni della licenza di Dataset A, sia le condizioni 
della licenza di Dataset B. 

Diversa però sarebbe la situazione se Sempronio si 
limitasse a diffondere Dataset A e Dataset B in un unico 
file di archiviazione (tipo ZIP), mantenendoli 
tecnicamente separati e indicando per ciascuno la 
titolarità del copyright e la licenza applicata. In questo 
caso si verificherebbe quella che comunemente 
chiamiamo “mera aggregazione” e non saremmo di 
fronte a un'attività di derivazione/integrazione, dato che 
il file ZIP non costituisce un dataset a sé e Dataset A e 
Dataset B rimangono separati. Ovviamente anche in 
questo caso Sempronio dovrebbe ottenere da Tizio e da 
Caio un permesso anche per la sola ripubblicazione dei 
dataset originari (che è comunque un'attività riservata) 
o verificare se tale attività è consentita dalle rispettive 
licenze. 


Semplice rielaborazione 
matematica di dati provenienti da 


dataset preesistenti 
Tizio realizza il Dataset A con i livelli di polveri sottili 
registrati da apposite centraline posizionate in tutti i 
comuni d’Italia e che rilevano il dato ora per ora, 


ottenendo così 24 valori per ciascun comune. Caio 
utilizza i dati contenuti nel Dataset A per realizzare un 
Dataset B più semplificato che non fa altro che dare un 
valore medio giornaliero per ciascun comune, quindi da 
24 valori per comune si passa a 1 valore per comune. 
Questo valore è ottenuto senza un’apprezzabile attività 
intellettuale bensì attraverso un banale calcolo 
matematico (una media), impostato automaticamente e 
scevro da un intervento intellettuale/creativo 
apprezzabile. Il Dataset B non contiene un’estrazione 
vera e propria dei valori del Dataset A perché nel 
Dataset B non si trovano valori presenti nel Dataset A, e 
dal Dataset B non è possibile risalire ai valori più 
dettagliati del Dataset A. Da un lato quindi verrebbe da 
pensare che il Dataset B non riproduce dati contenuti 
nel Dataset A; dall'altro lato tuttavia il Dataset B 
rappresenta comunque una forma di “reimpiego” di una 
parte sostanziale del dataset così come definito dall'art. 
7, co. 2 dalla Direttiva 96/9/CE. 


Il particolare caso della mera 


validazione di dati 

Quello della mera validazione dei dati contenuti in un 
Dataset preesistente è uno scenario molto interessante e 
abbastanza ricorrente in ambito scientifico. Ipotizziamo 
che Tizio realizzi il Dataset A con il livello di pericolosità 
sismica di una determinata faglia in dinamica storica, 
con tutti gli eventi sismici registrati negli ultimi cento 
anni. Caio analizza i dati presenti in Dataset A per 
procedere a una loro validazione tecnico-scientifica 


basata sulla sua maggiore esperienza nel settore e sulla 
base di altri dati fondamentali (per esempio: le 
caratteristiche del terreno) e pubblica un Dataset A-bis 
sostanzialmente identico, ma validato; cioè senza alcun 
intervento sui dati ma solo con l'indicazione che il 
dataset è stato da lui validato. Oppure semplicemente 
nel Dataset A-bis Caio riporta una colonna aggiuntiva 
con l'indicazione dei dati validati e dei dati non validati. 
È un caso giuridicamente interessante perché 
comunica efficacemente la differenza tra il diritto 
d'autore classico e il diritto sui generis sulle banche dati. 
Se parlassimo di un testo letterario o di un’opera 
musicale (cioè di opere tutelate da diritto d'autore), un 
intervento di validazione che non modifica l’opera in 
modo percepibile non potrebbe in alcun modo portare a 
un’opera derivata. Nel caso delle banche dati invece 
anche la mera attività di verifica di un database rientra 
nelle attività rilevanti ai fini della Direttiva 96/9/CE. 
L'art. 7, co. 1, precisa infatti che il costitutore di una 
banca dati non creativa è titolare del diritto sui generis 
“quando il conseguimento, la verifica e la presentazione 
del contenuto di una banca dati attestino un 
investimento rilevante sotto il profilo qualitativo o 
quantitativo”. A ben vedere, dunque, anche la semplice 
aggiunta di una colonna in una tabella di cento colonne 
rappresenta un'attività di reimpiego del dataset; attività 
che, benché possa risultare marginale a livello 
quantitativo, ha indubbiamente rilevanza sul piano 
qualitativo poiché va a modificare il concept generale 


del dataset, il suo valore e la sua possibilità di essere 
utilizzato da più utenti. 


Dataset realizzati attraverso un 
processo di modellazione di dati 
prelevati da un dataset 


preesistente 

Altro scenario abbastanza diffuso, che crea spesso 
fraintendimenti, è quello dell'attività di modellazione: 
mi riferisco ai modelli di previsione utilizzati per le 
previsioni meteo, per il calcolo del rischio sismico, per 
fornire proiezioni in finanza. Il modello è 
sostanzialmente un procedimento matematico che, a 
fronte di alcuni dati input, restituisce un output che 
appunto è la previsione/proiezione. Il modello quindi è 
più simile a software (opera tutelata dal diritto d’autore) 
e a un'espressione matematica (che teoricamente non 
potrebbe essere tutelata con diritto d'autore, ma più 
propriamente con l'applicazione del segreto industriale). 
A ogni modo, il modello è qualcosa di idealmente 
separato dai dati che esso “macina”, è un’opera 
dell'ingegno a sé stante. Ne consegue che il titolare dei 
diritti sul modello può essere un soggetto diverso da 
quello che realizza la banca dati da cui il modello estrae 
informazioni per fornire i suoi output. Ci si chiede quindi 
se vi sia un rapporto di derivazione tra i dataset input e 
il dataset prodotto dal modello come output; ma anche 
se vi sia un rapporto di derivazione tra i dataset input e 


il modello in sé. Lo focalizziamo meglio ponendo uno 
scenario ipotetico. 

Tizio realizza il Dataset A con le temperature registrate 
in una determinata zona negli ultimi tre giorni; Caio 
realizza un autonomo Dataset B con il tasso di umidità 
registrato nella stessa zona negli ultimi tre giorni; 
Sempronio realizza un autonomo Dataset C con la 
pressione atmosferica registrata nella stessa zona negli 
ultimi tre giorni. Mevio, ha realizzato un modello di 
calcolo che incrocia i dati presenti nei Dataset A, BeCe 
permette di creare un Dataset Z con la probabilità di 
precipitazioni nelle prossime ore in quell'area. Dataset Z 
dovrà essere considerato come dataset derivato dai 
Dataset A, B e C? La risposta è positiva. Il modello di 
calcolo può generare i suoi output e andare così a 
popolare il Dataset Z solo con un'attività di estrazione e 
reimpiego di parti sostanziali dei Dataset A, B e C. Ne 
consegue che colui che “fa girare il calcolo” e pubblica il 
Dataset Z dovrà avere ottenuto le adeguate 
autorizzazioni da parte dei titolari dei diritti dei Dataset 
input. In alternativa, i tre dataset di input dovranno 
essere rilasciati con licenze pubbliche che autorizzano 
quell’attività e dovranno inoltre essere tra loro 
compatibili; quindi il Dataset Z dovrà rispettare le 
indicazioni di titolarità dei diritti (c.d. attribution) di tutti 
i tre database input e la licenza scelta per il Dataset Z 
dovrà comunque essere compatibile con tutte e tre le 
licenze dei dataset di input. 


Rappresentazione grafica del 


contenuto di un dataset 

Altro scenario molto frequente è quello della 
rappresentazione grafica dei dati contenuti in una banca 
dati: grafici, tabelle, mappe e tutte le altre forme di data 
visualization. 

Mostrare una mappa con dei dati presi da un dataset 
crea un rapporto di derivazione? Indubbiamente si tratta 
di un'attività di “estrazione e reimpiego”; tuttavia 
bisogna ricordare che la direttiva del 1996 parla più 
propriamente di “estrazione e reimpiego di parti 
sostanziali” di una banca dati. Quindi la risposta al 
quesito diventa necessariamente “dipende”, perché va 
parametrata sul concetto di “parte sostanziale”. 

Benché sia più rara, si verifica anche la situazione 
opposta: utilizzare una mappa per estrarre informazioni 
e realizzare una banca dati. Una mappa non è una 
banca dati in sé bensì un’opera grafica tutelata da un 
diritto d'autore in senso classico; ma se si tratta di una 
mappa che riporta dei dati e se la raccolta di questi dati 
ha comportato per il suo autore un investimento 
rilevante, allora l'autore deterrà anche il famigerato 
diritto sui generis e potrà impedirne attività di 
estrazione e reimpiego dei dati. Anche in questo caso, 
comunque, per rispondere è necessario valutare se si 
tratti davvero di una parte sostanziale della banca dati. 

Altra variabile interessante da valutare nella 
rappresentazione di dati su mappa è l'aspetto - per così 
dire - informatico. Una mappa contenente dati può 
essere diffusa online come file raster, ma può anche 


essere rappresentata come un file vettoriale composto 
da una serie di “strati” trasparenti che idealmente si 
“appoggiano” su una mappa neutra. Nel caso della 
mappa raster ha in effetti senso chiedersi se vi sia un 
rapporto di derivazione tra la mappa e il dataset 
originario da cui sono tratti i dati rappresentati nella 
mappa. Nel caso di una mappa “a strati” in realtà la 
questione va considerata in modo diverso, poiché non è 
la mappa in sé a rappresentare i dati bensì i vari strati 
trasparenti che ad essa si sovrappongono; e la mappa 
rimane solo di sfondo. In questo caso quindi, a seconda 
di come viene impostata l'interfaccia utente che mostra 
i dati sulla mappa, è possibile mantenere separati i vari 
dataset facendo corrispondere a ciascuno di essi uno 
strato di dati. 

A complicare lo scenario intervengono anche i testi 
delle varie licenze d'uso per banche dati che, come 
vedremo, spesso contengono una definizione di “opera 
derivata” più precisa. In particolare vedremo nei 
prossimi paragrafi che la licenza OdbL (licenza open 
appositamente pensata per le banche dati) fa una 
distinzione tra Derivative Database e Produced Work, e 
dalle due diverse fattispecie fa dipendere diversi effetti 
giuridici. Come avremo modo di approfondire, il caso 
della realizzazione di una grafica o di una mappa basata 
sui dati di una banca dati rilasciata con licenza ODbL è 
proprio l'esempio più classico di Produced Work. 


governance dei dati 


può essere esercitata su diversi piani 


> 


piano tecnologico piano giuridico 


proprietà vincoli — 
intellettuale privacy / data contrattuali 


protection 





Figura 5.3 | piani su cui può essere esercitata la governance dei dati. 


Capitolo 6 


Le licenze open per dati e 
il fenomeno open data 


Il dibattito scientifico 
sull’open data e le direttive 
europee sulle public sector 

information 


Il dibattito sul tema open data si è animato nella 
seconda metà degli anni Duemila, in particolare in 
merito ai dati raccolti e gestiti dalle pubbliche 
amministrazioni e dagli enti di ricerca scientifica e 
statistico-sociale. Nonostante l’idea di massimizzare la 
libera disponibilità dei dati pubblici come forma di 
trasparenza dell'operato dell’amministrazione sia ben 
più antica, è la diffusione di Internet e delle tecnologie 
digitali come fenomeno di massa ad aver catalizzato 
l'attenzione sul tema. In altre parole, dal momento che 
ogni cittadino dispone potenzialmente degli strumenti 
per poter effettivamente accedere ai dati delle 
pubbliche amministrazioni ed elaborarli, ecco che il 
tema della trasparenza e dell'open data diventa centrale 
e strategico anche a livello politico. 


Come opportunamente suggerisce la relativa voce di 
Wikipedia: 
l'open data si richiama alla più ampia disciplina dell'open 
government, cioè una dottrina in base alla quale la pubblica 
amministrazione dovrebbe essere aperta ai cittadini, tanto in termini 
di trasparenza quanto di partecipazione diretta al processo 
decisionale, anche attraverso il ricorso alle nuove tecnologie 
dell’informazione e della comunicazione; e ha alla base un'etica 
simile ad altri movimenti e comunità di sviluppo “open”, come l'open 
source, l'open access e l'open content (cfr. 


Il tema non ha però riguardato solo il mondo della 
pubblica amministrazione, ma di riflesso ha coinvolto 
anche il mondo dei professionisti, delle imprese e del 
cosiddetto terzo settore. Anche questi soggetti hanno 
iniziato a interessarsi al tema e a pensare alla possibilità 
di estrarre valore (sia sul piano sociale sia sul piano 
economico) dai dati messi a disposizione dalle pubbliche 
amministrazioni. | più illuminati tra i soggetti privati 
hanno iniziato a rilasciare open data loro stessi 0 
quantomeno ad avviare progetti e collaborazioni con le 
pubbliche amministrazioni tra i cui obiettivi fosse 
compreso anche il rilascio e riuso di dati in modalità 
open. 

In questo contesto, si sono susseguiti vari interventi 
legislativi nella direzione del riuso dei dati pubblici. La 
principale spinta è venuta anche qui da direttive 
europee, le quali hanno a loro volta aperto la strada a 
importanti innovazioni nella normativa nazionale. 


Definizione di open data 


Ma che cosa si intende di preciso per “open data” e 
che cosa rende aperti i dati? Forniamo una definizione 
riportando un estratto dell'Open Data Handbook (cfr. 


divulgativo che a sua volta richiama la Open Definition: 


I dati aperti sono dati che possono essere liberamente utilizzati, 
riutilizzati e ridistribuiti da chiunque, soggetti eventualmente alla 
necessità di citarne la fonte e di condividerli con lo stesso tipo di 
licenza con cui sono stati originariamente rilasciati. 


E sempre secondo l'Open Data Handbook gli aspetti 
più importanti degli open data possono essere così 
riassunti: 


- Disponibilità e accesso: i dati devono essere disponibili nel loro 
complesso, per un prezzo non superiore ad un ragionevole costo di 
riproduzione, preferibilmente mediante scaricamento da Internet. | 
dati devono essere disponibili in un formato utile e modificabile. 


- Riutilizzo e ridistribuzione: i dati devono essere forniti a condizioni 
tali da permetterne il riutilizzo e la ridistribuzione. Ciò comprende la 
possibilità di combinarli con altre basi di dati. 


- Partecipazione universale: tutti devono essere in grado di usare, 
riutilizzare e ridistribuire i dati. Non ci devono essere discriminazioni 
né di ambito di iniziativa né contro soggetti o gruppi. Ad esempio, la 
clausola “non commerciale”, che vieta l’uso a fini commerciali o 
restringe l'utilizzo solo per determinati scopi (es. quello educativo) 
non è ammessa. 


Le principali norme in 
materia di open data e public 
sector information 


In questi paragrafi ricostruiamo in ottica storica 
l'evoluzione della normativa europea e italiana in 


materia di open data e di public sector information. 


Le direttive PSI sul riutilizzo dei 
dati pubblici 


L'acronimo PSI sta per Public Sector Information, cioè 
dati del settore pubblico, e viene in genere associato a 
una serie di tre direttive europee susseguitesi dal 2003 
in poi. 

La prima è stata la direttiva n. 2003/98/CE relativa al 
riutilizzo dell’informazione del settore pubblico, una 
direttiva che aveva lo scopo di spingere gli Stati membri 
a massimizzare il potenziale delle informazioni del 
settore pubblico promuovendone il riutilizzo sia tra gli 
stessi enti pubblici sia da parte dei cittadini e delle 
imprese. Come tutte le direttive, il principale intento è 
quello di creare un framework comune per tutti gli Stati 
membri ed evitare che norme nazionali troppo differenti 
tra loro generino una situazione frammentata e 
farraginosa in ottica di integrazione europea. Questa 
direttiva quindi ha rappresentato un primo importante 
passo per rimuovere (su scala sovranazionale e non più 
solo nazionale) le barriere che ostacolano il riutilizzo 
dell’informazione del settore pubblico nell'Unione 
Europea. 

Nel 2013, dopo un periodo storico di esplosione e 
diffusione di massa delle tecnologie informatiche e 
telematiche, si è reso necessario un aggiornamento del 
quadro normativo europeo in materia. La precedente 
direttiva è quindi stata riformata dalla direttiva n. 


2013/37/UE. Sul sito senato.it a tal proposito si legge 
quanto segue. 


La nuova direttiva PSI, salvo eccezioni specifiche, rende ora 
obbligatorio per gli enti pubblici di rendere riutilizzabili tutte le 
informazioni in loro possesso, sia per scopi commerciali e non 
commerciali, a condizione che le informazioni non siano escluse dal 
diritto di accesso ai sensi del diritto nazionale e in conformità alla 
normativa sulla protezione dei dati. 


Inoltre, è stato esteso l'ambito di applicazione della direttiva anche 
alle istituzioni culturali (biblioteche, comprese quelle universitarie, 
musei e archivi) in precedenza escluse, purché questi detengano i 
diritti di proprietà intellettuale. 


Tra le altre innovazioni introdotte si ricordano: 


- la riduzione delle tariffe applicabili in caso di riutilizzo, che sono 
limitate alla copertura dei soli costi di riproduzione, fornitura e 
diffusione; eccezioni sono consentite in un numero limitato di casi; 


- le istituzioni culturali possono impegnarsi nella concessione di diritti 
esclusivi di utilizzazione, se necessario per garantire progetti di 
digitalizzazione; 


- il rafforzamento dell'obbligo di trasparenza sulle condizioni e sulle 
tariffe applicate per il riutilizzo; 


- l'invito agli Stati membri a rendere disponibili quanto più possibile i 
documenti in formato aperto (tratto da 


Infine, nel giugno 2019 è stata approvata una terza 
direttiva: la direttiva n. 2019/1024/UE relativa 
all'apertura dei dati e al riutilizzo dell’informazione del 
settore pubblico. 

Tra le principali novità previste dalla prossima 
revisione della Direttiva PSI si evidenziano i seguenti 
aspetti: 


- Il principio generale secondo il quale tutti i contenuti del settore 
pubblico accessibili ai sensi delle norme nazionali siano resi 
disponibili gratuitamente per il riutilizzo. Gli enti pubblici non 
potranno imporre tariffe superiori ai costi marginali per il riutilizzo dei 
loro dati, tranne che in casi eccezionali. 


- La particolare rilevanza attribuita ad alcune tipologie di dati, definiti 
come dataset ad alto valore, quali le statistiche o i dati geospaziali, 
che hanno un notevole potenziale commerciale e possono accelerare 
lo sviluppo di un'ampia gamma di prodotti e servizi di informazione a 
valore aggiunto. 


- L'estensione dell'ambito di applicazione della direttiva alle imprese 
di servizio pubblico nel settore dei trasporti e dei servizi di pubblica 
utilità. Nel merito, la decisione sulla possibilità di rendere questi dati 
disponibili deve essere presa in base alle diverse normative nazionali 
o europee, ma - una volta resi disponibili per il riutilizzo - tali dati 
rientrano nell’ambito di applicazione della Direttiva PSI. Ciò 
comporterà che le imprese dovranno rispettare i principi della 
Direttiva e garantire l'uso di formati per i dati e di metodi di 
diffusione appropriati. 


- L'adozione di misure di salvaguardia per rafforzare la trasparenza e 
limitare la conclusione di accordi che potrebbero portare a un 
riutilizzo esclusivo dei dati del settore pubblico da parte dei partner 
privati. 


- La maggiore disponibilità di dati in tempo reale mediante l’uso di 
interfacce API (Application Programming Interfaces) al fine di favorire 
lo sviluppo di prodotti e servizi innovativi (ad esempio applicazioni 
per la mobilità) da parte delle imprese e, soprattutto, delle start up. 


- L'estensione dell'ambito di applicazione della direttiva anche ai dati 
della ricerca finanziata con fondi pubblici: gli Stati membri saranno 
tenuti a elaborare politiche per l’accesso aperto ai dati della ricerca 
finanziata con fondi pubblici, mentre a tutti i dati di tale natura, resi 
accessibili tramite archivi, saranno applicate norme armonizzate in 
materia di riutilizzo. 


NOTA 
Tratto da https://www.agid.gov.it/it/agenzia/stampa-e- 


riutilizzo-dellinformazione-del-settore. 


La direttiva INSPIRE e i dati 


ambientali/territoriali 


NOTA 
L'intero paragrafo riproduce il testo pubblicato su 
https://ww.minambiente.it/pagina/inspire. 


La direttiva n. 2007/2/CE del Parlamento Europeo e del 
Consiglio del 14 marzo 2007 ha istituito INSPIRE 
(acronimo di INfrastructure for SPatial InfoRmation in 
Europe), recepita nell'ordinamento italiano con il 
decreto legislativo 27 gennaio 2010, n. 32, con cui è 
stata istituita in Italia l'Infrastruttura nazionale per 
l'informazione territoriale e del monitoraggio 
ambientale, quale nodo dell’infrastruttura comunitaria. 

INSPIRE e, nel suo ambito, l’Infrastruttura nazionale 
hanno lo scopo di rendere omogenee e condivisibili, 
all’interno dell’Unione Europea, le informazioni 
georeferenziate di carattere ambientale, affinché queste 
siano di supporto alle politiche ambientali o per ogni 
altra attività che possa avere ripercussioni 
sull'ambiente. 

Il D.Lgs. n. 32/2010 delinea la governance per lo 
sviluppo e la gestione dell’Infrastruttura nazionale per 
l'informazione territoriale e del monitoraggio ambientale 
nell’ambito di INSPIRE. 

La funzione dell’informazione territoriale quale 
supporto alle politiche ambientali, già palese nella 
direttiva UE del 2007, è stata recepita in modo chiaro 
dal legislatore italiano, che ha inteso espressamente 


richiamare il riferimento alla Comunicazione della 
Commissione Europea SEIS (Shared Environmental 
Information System). 

Il legislatore ha anche individuato il necessario 
raccordo tra il D.Lgs. n. 32/2010 “INSPIRE” e il D.Lgs. n. 
195/2005 relativo all'accesso del pubblico 
all'informazione ambientale. In particolare è stato 
espressamente previsto che l’indice digitale dei 
cataloghi pubblici dell’informazione ambientale sia una 
delle componenti dell’Infrastruttura nazionale INSPIRE. 


Il Codice dell’amministrazione 
digitale e i decreti su trasparenza 
pubblica e FOIA 


A livello di normativa nazionale, furono molti gli 
interventi legislativi mirati a recepire i principi delle 
direttive. A ogni modo, i più rilevanti sono le più recenti 
modifiche al Codice dell’amministrazione digitale (il 
D.Lgs. n. 82/2005, anche detto CAD), nonché i cosiddetti 
Decreto Trasparenza (D.Lgs. n. 33/2013) e Decreto 
“FOIA” (D.Lgs. n. 97/2016, dove l'acronimo sta per 
Freedom Of Information Act). 

In particolare, il cosiddetto Decreto Crescita 2.0, 
convertito poi nella Legge n. 221/2012, ha introdotto 
all'articolo 52 del CAD quello che viene di solito definito 
“principio open by default sui dati e sui documenti della 
pubblica amministrazione”. AI comma 2 della norma si 
legge: 


I dati e i documenti che [le pubbliche amministrazioni] pubblicano, 
con qualsiasi modalità, senza l’espressa adozione di una licenza [...] 


si intendono rilasciati come dati di tipo aperto [...] [la norma rimanda 

alla definizione di “dato aperto” fornita all'articolo 1, comma 1, 

lettere |-bis) e I-ter)], del presente Codice, ad eccezione dei casi in cui 

la pubblicazione riguardi dati personali. 

Il principio è particolarmente “scaltro”, perché in 
sostanza permette di sfruttare l'inerzia delle pubbliche 
amministrazioni che spesso, pur mettendo a 
disposizione sui loro siti web dati e documenti di 
interesse pubblico, non provvedono a corredarli con una 
licenza open. In virtù dell'articolo 52 cittadini, imprese e 
altre pubbliche amministrazioni possono di fatto 
utilizzare quei dati e documenti come se fossero “aperti” 
anche in mancanza di una licenza esplicita. 

Il Decreto Trasparenza e il Decreto FOIA non si sono 
espressamente occupati dell'aspetto delle licenze open 
sui dati pubblici. In compenso hanno individuato con 
chiarezza le tipologie di dati sottoposti a un obbligo di 
pubblicazione (cosiddetti dati a pubblicazione 
obbligatoria) e indicato le sanzioni a carico dei 
funzionari che non rispettano questi obblighi. 

Tuttavia, come ho già avuto modo di sottolineare in 
varie sedi, a mio parere il meccanismo dell'open by 
default ha alcuni pesanti limiti. Innanzitutto è oltremodo 
“contorto” da un punto di vista giuridico, perché 
inserisce un principio relativo all'utilizzo di opere 
dell'ingegno in un testo normativo che si occupa di 
pubblica amministrazione senza però andare a 
modificare le norme della legge sul diritto d'autore, 
aumentando il rischio di contraddizioni e antinomie fra 
testi normativi molto lontani tra loro e appartenenti ad 
ambiti molto diversi. 


Inoltre l'open by default spesso rischia di non 
funzionare per il semplice motivo che da un lato il 
meccanismo scatta solo quando la licenza manca del 
tutto, dall'altro però non si sa sempre con certezza se 
davvero la licenza non ci sia o se sia stata solo nascosta 
bene o anche sia temporaneamente “dispersa”. 

Tutte le volte che un cliente mi ha incaricato di 
verificare quali fossero i termini di utilizzo di un dataset 
pubblico, mi sono trovato a dovermi barcamenare in siti 
web non aggiornati, con pagine “copyright” con link 
rotti, con rimandi a pagine “copyright” di altri siti web 
(ancora più vecchi), oppure con pagine “copyright” così 
criptiche e fantasiose da non permettermi di esprimere 
un parere legale solido e univoco. A volte non vi è 
traccia di licenze o di disclaimer sul copyright in tutto il 
sito web della pubblica amministrazione esaminata, 
salvo poi trovare una licenza o un disclaimer sotto forma 
di un file “read me” annegato all’interno di un archivio 
ZIP assieme a decine o centinaia di file in vari formati 
(che contengono i dati). 

Ne consegue che spesso chi fa il lavoro di consulente 
su questi temi si trova costretto a mantenere un 
approccio prudente e suggerire al cliente di contattare il 
titolare dei vari siti web, con il rischio di “svegliare il 
cane che dorme” e attivare un effetto controproducente. 


NOTA 
Si veda anche “Open data: serve una norma più chiara. L'open by 
default non funziona” (https://ww.techeconomy2030.it/2018/12/28/0pen- 


Le licenze open per opere 
non software: dalla GNU FDL 
alle Creative Commons 


Quasi per gemmazione dal modello delle licenze per 
software open source, già alla fine degli anni Novanta 
erano circolate le prime bozze di licenze che cercavano 
di riprodurre gli stessi effetti sulle opere diverse dal 
software. 

La breccia fu aperta proprio nel campo delle 
pubblicazioni tecniche legate al settore informatico. 
Infatti, con la progressiva diffusione del software libero e 
open source, ci si è spesso trovati di fronte a un 
paradosso: tutta la documentazione (istruzioni tecniche, 
manuali, presentazioni) relativa al software libero e 
prodotta dagli stessi sviluppatori rimaneva in un regime 
di copyright tradizionale, dato che - come abbiamo 
spiegato - il copyright scatta in automatico. 

Molti autori, soprattutto i “guru” del movimento del 
software libero, pubblicavano i loro articoli di 
divulgazione e sensibilizzazione accompagnati da una 
breve nota di copyleft che suonava più o meno così: “È 
permessa la copia letterale dell’opera con ogni mezzo a 
condizione che venga riportata questa nota”. In questa 
laconica frase si condensa in effetti molto efficacemente 
il senso pratico del modello copyleft persistente; dal 
punto di vista giuridico però tale laconicità poteva 
essere foriera di abusi e interpretazioni fuorvianti. Tra 
l’altro l’uso di questa nota nel caso di documentazione 
poteva non essere particolarmente appropriato poiché 


non si contemplava la possibilità di modifica dei 
contenuti dell’opera: possibilità determinante 
trattandosi di manuali di software liberamente 
modificabile, oltre che liberamente copiabile. 

Alcuni autori scelsero di applicare la GNU GPL anche 
alle opere di documentazione, ma come è già emerso si 
tratta di una licenza pensata per un’opera tecnico- 
funzionale come il software. Ecco che nel 2000 nacque 
(sempre in seno al progetto GNU) la Free Documentation 
License: una licenza appositamente pensata per le opere 
letterarie, dunque una delle prime licenze copyleft 
dedicate al mondo dei contenuti e non solo in senso 
stretto al software. 

Sulla scia di questa nuova prassi e più in generale 
sulla spinta della diffusione massiccia di Internet, si 
attivarono alcuni progetti di promozione della libera 
circolazione delle opere creative. Ogni progetto propose 
la propria “ricetta” per sdoganare i principi 
dell’openness anche in quell’ambito non più 
strettamente informatico: nacquero così alcune licenze 
come la Open Publication License (del progetto 
OpenContent), la OpenAudio License (della Electronic 
Frontier Foundation), la OpenMusic License (del progetto 
tedesco OpenMusic), la Licence Art Libre (del progetto 
francese Art Libre). 

Fu però un gruppo di ricercatori prima con sede a 
Cambridge in Massachusetts e poi in California nella Bay 
Area e capitanato dal professor Lawrence Lessig a fare il 
passo più determinante in questo senso, con 
l'avviamento del progetto Creative Commons e la 


diffusione nel 2002 delle relative licenze (Figura 6.1). Si 
tratta di licenze pensate per poter funzionare con tutti i 
tipi di opere creative e in modo da poter essere tradotte 
e adattate ai vari ordinamenti giuridici; inoltre la loro 
struttura si articola in clausole modulari che permettono 
all'autore di decidere quali usi consentire per la sua 
opera, a quali condizioni e in quali contesti: in poche 
parole, consentono all'autore di graduare la libertà di 
utilizzo dell’opera, chiarendone le condizioni. 

A oggi le licenze Creative Commons sono sei e 
prendono il nome dalle clausole in esse contenute. In un 
ordine dalla più permissiva alla più restrittiva esse sono: 


Attribuzione; 

Attribuzione - Condividi allo stesso Modo; 
Attribuzione - Non opere derivate; 

Attribuzione - Non commerciale; 

Attribuzione - Non commerciale - Condividi allo 
stesso Modo; 

6. Attribuzione - Non commerciale - Non opere 
derivate. 


U SWINFE 


Alle sei licenze si aggiunge poi il CCO (CC Zero), 
strumento per il rilascio in pubblico dominio di cui 
parleremo poco più avanti. 
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Figura 6.1 Ottima infografica (realizzata da Foter e tradotta in italiano 
dall'autore del libro) che riassume con successo il significato e le 
implicazioni giuridiche delle licenze Creative Commons. L'immagine è 
disponibile anche su Wikimedia Commons 
(https://commons.wikimedia.org/wiki/File:Creative Commons _Licenses.png) 
in versione leggermente modificata da altro autore. Essa è a sua volta 
tratta da un’infografica più ampia, disponibile sul blog ufficiale di Foter 
(https://foter.com/blog/how-to-attribute-creative-commons-photos/). L'opera 


è rilasciata con licenza Creative Commons Attibution-ShareAlike 3.0 
Unported. 


Licenze che però non 
licenziano 


Quando a metà degli anni Duemila si iniziò a parlare di 
open data si pensò che licenze come le Creative 


Commons potessero essere tranquillamente utilizzate 
anche per le banche dati. E infatti fu proprio la strada 
che fu seguita dai primi progetti di raccolta e diffusione 
di dati con approccio aperto. 

Tuttavia emerse presto un problema non irrisorio. Le 
licenze Creative Commons come anche la GNU FDL e le 
altre simili “vivono” e funzionano all’interno dei confini 
del diritto d'autore in senso più classico; sono infatti 
pensate per opere letterarie, opere musicali, opere 
grafiche ecc. Non sempre ciò implica che esse 
contemplino un diritto chiamato appunto “sui generis” 
che si allontana in alcuni aspetti dal diritto d’autore in 
senso stretto. Dunque il loro utilizzo nel campo delle 
banche dati in ambito europeo rischia di lasciare 
scoperta la parte relativa al diritto sui generis. 

Cerchiamo di intenderci meglio. La funzione di queste 
licenze è quella di autorizzare, consentire, appunto 
“licenziare” alcuni usi liberi dell’opera cui la licenza è 
riferita; e per farlo il testo delle licenze fa esplicito 
riferimento ai singoli diritti coinvolti nella cessione. Ma 
non tutte queste licenze prendono in considerazione 
espressamente il cosiddetto diritto sui generis. 

C'è un motivo per tutto questo: gran parte di queste 
licenze, pur essendo state presto “esportate” in Europa, 
sono state concepite in seno all'ordinamento giuridico 
statunitense, nel quale non esiste questo duplice livello 
di tutela per le banche dati. 

In sostanza, qualora ci trovassimo di fronte a una 
banca dati rilasciata con una di queste licenze, non 
potremmo sentirci autorizzati a utilizzarla liberamente, 


poiché, salvo espressa integrazione del testo della 
licenza, il titolare dei diritti (il costitutore) manterrebbe 
la piena ed esclusiva titolarità del diritto sui generis. 
Bisogna quindi riflettere su quale sia il modo più 
efficiente di gestire questa particolare tipologia di diritti 
e in sintesi ci troviamo a una duplice via d'uscita: o Si 
opta per una rinuncia all’esercizio di questi diritti, 
oppure si opta per un loro licenziamento specifico. 


La soluzione del rilascio in 
pubblico dominio 


La prima delle due vie percorribili è appunto quella di 
procedere con una rinuncia da parte del costitutore 
all'esercizio dei suoi diritti sul database, prima che siano 
trascorsi i quindici anni previsti dalla direttiva e che 
appunto il database entri in modo definitivo in una 
condizione di pubblico dominio. 


NOTA 

Per la precisione, il periodo di quindici anni solari deve trascorrere 

senza che il costitutore attui un nuovo investimento rilevante per la 

modifica o l'aggiornamento del database. In quel caso infatti il 

termine dei quindici anni riparte dalla data del sopravvenuto 

investimento/aggiornamento, con l’effetto che, di fatto, il database 
non giunge mai a una situazione di reale pubblico dominio. 

Per raggiungere questo effetto è necessario che il 
titolare dei diritti rilasci una dichiarazione pubblica in 
cui si impegna a rinunciare all'esercizio degli stessi in 
modo illimitato e incondizionato. 

Si tratta di una soluzione già sperimentata con 


successo in riferimento ai diritti d'autore: si pensi al CCO 


(CC Zero) proposto da Creative Commons, o alla PDDL 
(Public Domain Dedication and License) proposta dal 
Progetto Open Data Commons, strumenti con i quali è 
possibile per un titolare di diritti rilasciare la propria 
opera in una sorta di pubblico dominio artificiale (Si 
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Figura 6.2 La versione sintetica di CCO che compare sul sito di Creative 
Commons. 


Di certo tale soluzione risulta quella che, da un lato, 
garantisce la maggiore libertà d’uso del database e, 
dall'altro, crea meno problemi dal punto di vista della 
diffusione e dell'utilizzo del database su scala 
internazionale. Infatti, nel caso in cui il costitutore di un 
database di origine europea decidesse di rinunciare 
all'esercizio del diritto sui generis, consentirebbe al suo 


prodotto di circolare liberamente senza che vi siano 
dubbi sui regimi di tutela da applicare. Di riflesso, un 
utente extraeuropeo non dovrebbe interrogarsi sul fatto 
che il database, provenendo da un contesto europeo, 
possa avere un regime di tutela diverso da quello del 
suo Paese. 

L'approccio della rinuncia all'esercizio del diritto SU/ 
generis è stato seguito da Creative Commons non solo 
con l'invito a utilizzare il più possibile lo strumento CC0 
per il rilascio di database, ma anche inserendo 
un'apposita clausola di rinuncia (waiver) all’interno delle 
licenze nella versione 3.0. 

Infatti, le licenze Creative Commons nella loro 
concezione originaria non consideravano espressamente 
i cosiddetti database rights (cioè i particolari diritti sulle 
banche dati). Nei Paesi europei ci si è posti dunque il 
problema che quelle licenze, diventate ormai uno dei 
principali punti di riferimento per la libera distribuzione 
delle opere dell'ingegno, restassero tagliate fuori dal 
campo di applicazione dei database. 

Si avvertì perciò la necessità di adattare le versioni 
localizzate nei Paesi europei in modo tale che potessero 
licenziare anche il diritto sui generis. Questo processo di 
adattamento ha richiesto una lunga riflessione e un 
confronto costante fra i vari gruppi di lavoro nazionali 
del progetto Creative Commons, e si è concluso con il 
rilascio in buona parte dei Paesi europei della versione 
3.0 delle licenze, nelle quali sono espressamente 
menzionati i database rights. L'annuncio pubblico 
ufficiale delle licenze italiane in versione 3.0 è avvenuto 


nel giugno 2011. Tuttavia si tratta solo di un passaggio 
intermedio. Infatti nella versione 3.0 non sono inserite 
clausole che davvero licenziano il diritto su/ generis; ma 
semplicemente è stata inserita una clausola che attua 
una rinuncia al diritto sui generis come avviene per il 
CCO. 

Dal comunicato di CC si estrae un interessante 
riferimento alle novità in fatto di diritto sui generis: 


In Europa le licenze CC devono confrontarsi con il cosiddetto diritto 
“sui generis” sulle banche dati. Quest'ultimo, a differenza del diritto 
d'autore, finisce per proteggere il contenuto dei database e per 
questa ragione si tratta di una norma insidiosa, specie in ambiti 
come la ricerca scientifica. Creative Commons Science ha sottolineato 
come l’esistenza di tale diritto su opere scientifiche contenenti 
banche dati e rilasciate sotto licenza CC rischiasse di vanificare 
completamente le finalità della licenza stessa in ambito europeo. Le 
licenze CC 3.0 europee sono dunque caratterizzate dalla completa 
rinuncia a far valere il diritto sui generis sulle banche dati: resta 
comunque tutelato il diritto d'autore per quel che riguarda la 
struttura della banca dati, assieme ad altre caratteristiche 
“espressive” della stessa. Ma è garantito il libero utilizzo dei fatti e 
delle informazioni contenute nella banca dati (cfr. 


Le licenze open per dati 


Ci sono casi in cui però non è sempre praticabile la 
soluzione della rinuncia (con rilascio in pubblico 
dominio) e quindi bisogna licenziare puntualmente il 
diritto sui generis. Ci si riferisce per esempio a quei casi 
in cui il detentore dei diritti intenda rilasciare il database 
con specifiche condizioni, come per esempio 
l'attribuzione di paternità o il cosiddetto “share alike”. In 
quei casi infatti si farebbe leva proprio sul diritto SU/ 


generis (essendo questo l’unico diritto a disposizione del 
costitutore) per imporre le condizioni di utilizzo. 

Ci si è quindi attivati per redigere delle licenze 
pensate apposta per agire anche sul diritto sui generis e 
quindi efficaci anche nel licenziare banche dati tutelate 
da quel diritto. 

Sono in genere divise in due categorie: le licenze di 
mera attribuzione e le licenze con attribuzione e 
clausola propagativa (cosiddetta “share alike”). 

Restano invece fuori dalla nostra analisi le licenze con 
clausole che vietano le derivazioni e rielaborazioni (tipo 
le Creative Commons con clausola No Derivatives) e le 
licenze con clausole che vietano gli utilizzi commerciali 
(tipo le Creative Commons con clausola Non 
Commercial), poiché tali licenze non rispetterebbero 
comunque la più accreditata definizione di open data 
(Figura 6.3). 


STRUMENTI PER IL RILASCIO DI OPEN DATA 


licenze d’uso 
de 


dichiarazioni 


i rsa ta solo con richiesta QIIISRA 
pubblico dominio attribuzione e di 


ai RI IUZIONe applicazione della 
stessa licenza 


e CCO ® 
e ODC PDDL e CC BY 4.0 @ 


e ODC-BY e CC BY-SA 4.0 


e /ODL 2.0 e ODC ODbL 


e JODL 1.0 





Figura 6.3 | principali strumenti giuridici per il rilascio di open data. Sono 
state escluse licenze con limitazioni sulle opere derivate e sugli usi 


commerciali perché non coerenti con la più accreditata definizione di open 
data. 


Le licenze con clausola 


propagativa (share alike) 

Come abbiamo spiegato, fino all'arrivo delle versioni 
4.0 le licenze Creative Commons non si preoccupavano 
davvero di licenziare il diritto sui generis ma si 
limitavano a un atto di rinuncia. 

Nel 2008 è stato avviato anche un progetto 
indipendente mirato alla creazione di una licenza 
pensata proprio per le banche dati. Si tratta di un 
progetto britannico, nato in seno all’Università di 
Edimburgo per iniziativa di un giurista texano 
trasferitosi in Scozia per la sua attività di ricerca e 
insegnamento: il professor Jordan Hatcher. 

NOTA 

Alcuni degli attivisti impegnati in questo progetto si erano in 

precedenza occupati di un’altra licenza dello stesso tipo, in verità 

abbastanza approssimativa e quasi subito abbandonata: la Talis 

Community Licence. 

Il frutto più importante di questo progetto, 
denominato appunto Open Data Commons, è stato il 
rilascio della licenza Open Database License (ODDL). Il 
testo integrale della licenza è disponibile all’URL 


http://ww.opendatacommons.org/licenses/odbl/. 


La ODbL è una licenza piuttosto complessa ma ben 
fatta; e può attuare con successo il modello copyleft in 
ambito di banche dati. Contiene infatti una serie di 
clausole che riproducono il modello delle licenze 


Attribution - Share Alike proposte da Creative Commons. 
Essa licenzia unicamente i diritti relativi al database; 
dunque, qualora si tratti di un database contenente 
opere creative, per garantire un libero utilizzo dell'intera 
opera è opportuno applicare un’altra licenza sulle opere 
contenute nel database stesso. Si legga infatti quanto 
precisato nel preambolo della licenza: 


La Banca Dati può accogliere una grande varietà di contenuti 
(immagini, materiale audiovisivo e sonoro, tutto in una stessa Banca 
Dati, per esempio) e di conseguenza la ODbL si limita a 
regolamentare i diritti sulla Banca Dati, ma non quelli sui contenuti 
della Banca Dati considerati individualmente. | Concedenti (come 
definiti più oltre) dovrebbero usare la ODbL collegandola ad altra 
licenza per i contenuti, se tali contenuti soggiacciono alla medesima 
regolamentazione di diritti che copra uniformemente tutti i contenuti 
stessi. Se esistono differenti tipi di diritti per questi contenuti, i 
Concedenti dovrebbero specificare, nella nota individuale o in altro 
modo che chiarisca il diritto concretamente applicabile, quali diritti 
regolamentano i singoli contenuti e se determinati contenuti sono 
regolati da uno stesso diritto. 


Ciò implica che sia necessaria una certa accortezza 
nella scelta della licenza per i contenuti: per non creare 
ulteriori complicazioni è consigliabile scegliere una 
licenza che riproduca gli stessi effetti anche peri 
contenuti. 

Caratteristica peculiare e interessante della ODDbL è la 
distinzione tra “derivative database” e “produced work”, 
che in effetti in alcuni casi risulta funzionale (come nel 
caso dei dati geografici del progetto OpenStreetMap e 
delle mappe realizzate sulla base di questi dati) e della 
quale parleremo più nel dettaglio tra qualche paragrafo. 


Le licenze di mera attribuzione 

Le licenze di mera attribuzione sono l'equivalente di 
quelle che nell'ambito software abbiamo chiamato 
“licenze permissive”. Esse lasciano la più ampia libertà 
di utilizzo ai licenziatari con l’unica condizione di 
indicare la fonte originaria dei dati. 

Come abbiamo spiegato, fino all'arrivo delle versioni 
4.0 (risalente al novembre 2013) le licenze Creative 
Commons non si preoccupavano davvero di licenziare il 
diritto sui generis ma si limitavano a un atto di rinuncia. 


NOTA 
Si veda il comunicato stampa di Creative Commons con l'annuncio 
della nuova versione 4.0: https://creativecommons.0rg/2013/11/26/press- 


A oggi la licenza di mera attribuzione per banche dati 
più utilizzata e più consigliabile è senza dubbio la 
Creative Commons Attribution 4.0 (CC BY 4.0). Non a 
caso le linee guida italiane in materia di open data 
pubblici (Linee guida nazionali per la valorizzazione del 
patrimonio informativo pubblico) esprimono nell’Azione 
n. 12 un'esplicita preferenza per questa licenza. 


NOTA 

Il documento. integrale, una volta pubblicato e aggiornato 
dall'Agenzia per l’Italia Digitale (AgID), risiede a oggi sul sito del 
Team per la Trasformazione Digitale della Presidenza del Consiglio dei 
Ministri: https://docs.italia.it/italia/daf/lg-patrimonio- 


Si ritiene opportuno fare riferimento ad una licenza unica aperta, che 
garantisca libertà di riutilizzo, che sia internazionalmente riconosciuta 
e che consenta di attribuire la paternità dei dataset (attribuire la 
fonte). Pertanto, si suggerisce l'adozione generalizzata della licenza 
CC BY nella sua versione 4.0, presupponendo altresì l'attribuzione 


automatica di tale licenza nel caso di applicazione del principio “Open 

Data by default”, espresso nelle disposizioni contenute nell'articolo 

52 del CAD. 

Tuttavia, prima che arrivasse la CC BY 4.0, il già citato 
progetto Open Data Commons nel 2010 si era attivato 
per redigere e mettere a disposizione una licenza di 
mera attribuzione per banche dati “sorella minore” della 
ODbL e denominata appunto ODC Attribution License 
(ODC BY). Il testo integrale della licenza è disponibile 

Anche la IODL 2.0 rientra in questa categoria di 
licenze, ma, come per tutte le licenze di respiro solo 
nazionale o addirittura regionale, consiste in una 
soluzione subottimale rispetto all'utilizzo di una CC BY 
4.0 che è conosciuta e applicata con successo in tutto il 
mondo. 


Alcune licenze “governative” per i 
dati pubblici 


Dal canto loro, i governi dei Paesi UE, nell’ambito del 
perseguimento degli obiettivi indicati dall'Unione 
Europea con le già citate direttive sulla condivisione 
delle public sector information, si sono attivati per 
redigere licenze all'uopo. 

Degne di nota sono la Open Government Licence for 
public sector information del Regno Unito (il testo 
integrale della licenza è disponibile qui: 


http://ww.nationalarchives.gov.uk/doc/open-government-licence/ve rsion/3/) j | 


cui scopo è quello di rilasciare in modalità open con 
mera attribuzione le informazioni (intese sia come 


contenuti sia come dati) prodotte dalle istituzioni 
britanniche; e la francese Licence Information Publique 
(il testo integrale della licenza è disponibile qui: 
http://xw.rip.justice.fr/information publique librement reutilisabte), Che 
però pone la condizione di rispettare l'integrità dei dati 
(come in una Creative Commons No Derivatives) e 
quindi si pone al di fuori della più accreditata 
definizione di open data. 

In Italia è stata anche rilasciata una licenza chiamata 
Italian Open Data License (IODL) (per maggiori dettagli: 
verità in modo un po’ approssimativo) su una Creative 
Commons Attribution - Share Alike e rilasciata nella sua 
prima versione nell'ottobre del 2011. Dopo alcuni mesi 
(nel marzo 2012) è stata rilasciata una sua seconda 
versione, più simile a una licenza con mera attribuzione 
e corredata di alcune clausole di compatibilità a favore 
di licenze più note e solide come la Creative Commons 
Attribution e la ODbL, così da agevolare un progressivo 
abbandono della licenza nazionale a favore di tali 
licenze internazionali. A oggi l'utilizzo della IODL non 
viene più incoraggiato nell’ambito delle pubbliche 
amministrazioni italiane, ma si preferisce la CC BY 4.0. 


Un breve confronto tra CC BY-SA e 


ODbL 
La ODDbL risulta più flessibile rispetto alla CC BY-SA 4.0 
poiché quest’ultima applica lo “share alike” a qualsiasi 
forma di derivazione; la ODbL invece fa un’opportuna 


distinzione tra banca dati derivata e opera derivata, 
distinzione che si comprende meglio facendo riferimento 
alle definizioni fornite dalla licenza stessa. Il testo della 
licenza ODbL in traduzione italiana è disponibile qui: 
https://it.okfn.org/odbl-1-0/. 

Una banca dati derivata (nel testo inglese “derivative 
database”) è “una banca dati basata sulla banca dati 
licenziata, e include ogni traduzione, adattamento, 
arrangiamento, modifica, od ogni altra alterazione della 
banca dati o di una parte sostanziale dei suoi contenuti; 
ciò include anche estrazione o riutilizzo di tutti o di una 
parte sostanziale dei contenuti in una nuova banca 
dati”. Invece un’opera derivata (nel testo inglese 
“produced work”) è “un’opera creativa (come 
un'immagine, un video, un testo, un suono) risultante 
dall'utilizzo di tutti o di una parte sostanziale dei 
contenuti della banca dati licenziata o di una banca dati 
derivata”. Secondo i termini della licenza, infatti, il 
cosiddetto effetto “share alike” si produce solo nel caso 
di realizzazione di una banca dati derivata; nel caso 
invece di realizzazione di un’opera derivata (classico 
esempio: una mappa che rappresenta i dati) la licenza si 
comporta come una semplice “attribution”. Lo dispone la 
Sezione 4.3 della licenza, in cui si legge: 


Creare e usare un’opera derivata non richiede l'inserimento 
dell'avviso di cui alla Sezione 4.2 [cioè il disclaimer con cui si 
richiama e si applica la stessa licenza anche alle derivazioni]. 
Comunque, se usi pubblicamente un’opera derivata, tu devi 
includere un avvertimento associato all'opera derivata, 
ragionevolmente idoneo affinché ogni persona che usi, guardi, 
acceda, interagisca o entri altrimenti in contatto con l’opera derivata 


sia messa a conoscenza che i Contenuti sono stati ottenuti dalla 
banca dati [...] e che sono disponibili ai sensi di questa Licenza. 


La clausola propagativa 
nell’ambito dati e i relativi 
problemi di compatibilità tra 
licenze open data 


Già nel paragrafo “| concetti di ‘derivazione’ e 
‘integrazione’ nel mondo delle banche dati” abbiamo 
spiegato quanto i concetti di “derivazione” e di 
“integrazione” possano risultare problematici nel mondo 
delle banche dati. Sono proprio quei problemi a rendere 
sdrucciolevole il terreno per tutte le licenze che 
contengono clausole propagative, cioè quelle clausole 
che nel gergo del software libero vengono chiamate 
“copyleft” e nel gergo di Creative Commons vengono 
chiamate “share alike”. Ci riferiamo quindi soprattutto 
alla licenza CC BY-SA (Creative Commons Attribution - 
Share Alike, in versione 4.0) e alla licenza ODbL (Open 
Database License). Non terremo in considerazione l’altra 
licenza Creative Commons con clausola Share Alike (cioè 
la Creative Commons Attribution - Non Commercial - 
Share Alike) poiché sarebbe comunque contraria alla 
definizione più accreditata di “open data”, la quale non 
ammette il “Non Commercial”. 

Come avviene nell’ambito del software libero, se 
troviamo un database rilasciato con una di queste 
licenze, possiamo realizzare un database derivato solo 
se poi anche il database derivato verrà rilasciato con la 


stessa licenza (o al massimo con una versione più 
aggiornata della stessa); e lo stesso accadrà con un 
database a sua volta derivato dal database derivato, e 
così via a cascata. Questo comporta che, nel momento in 
cui decido di applicare a un database una licenza di quel 
tipo, devo essere consapevole del fatto che tale scelta 
poi condizionerà “all'infinito” le attività di derivazione e 
integrazione sul database da me rilasciato e avrà 
ripercussioni di lungo periodo sui vari progetti che 
saranno interessati a riutilizzare e integrare il mio 
database. Essi infatti dovranno aderire a loro volta alla 
stessa licenza, a meno di non contattarmi per ottenere 
un'autorizzazione specifica. Se quei progetti, per loro 
policy o per altre ragioni, non potessero utilizzare la 
licenza da me scelta, non potranno far altro che non 
integrare il mio database con i loro dati e quindi, in caso 
di ridistribuzione dei dati da parte loro, saranno costretti 
a tenere il mio database separato con una separata 
indicazione di licenza. 

Ecco perché suggerisco di riflettere bene prima di 
utilizzare quelle licenze nel campo degli open data. Se 
l’obiettivo del nostro progetto open data è quello di 
essere davvero open e quindi massimizzare il potenziale 
di riuso dei nostri dati, una licenza con clausola 
propagativa potrebbe risultare addirittura 
controproducente. 

Non a caso, come abbiamo già spiegato, gli autori 
della ODbL hanno pensato di ammorbidire l’effetto 
propagativo facendo una distinzione tra banca dati 
derivata e opera derivata. 


La tabella in Figura 6.4 (di cui esiste una versione più 
ampia, che comprende anche altre licenze, non coerenti 
con la definizione di open data) mostra quali possono 
essere i rapporti di compatibilità (o di “interoperabilità”, 
come la chiama l’autore) tra le principali licenze per 
banche dati. 

Emerge con sufficiente chiarezza che le soluzioni che 
garantiscono massima possibilità di combinazione tra 
database diversi e quindi massima possibilità di 
riutilizzo dei dati in ottica open data sono le 
dichiarazioni di rilascio in pubblico dominio (CC0 e 
simili) o le licenze di mera attribuzione. Le licenze con 
clausola share alike creano non poche incognite. 
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La creazione di un’opera derivata e la sua pubblicazione è possibile 





La creazione di un’opera derivata potrebbe essere possibile ma vi è incertezza (ad esempio sui diritti 
licenziati) circa l'effettiva compatibilità o altri problemi (problema di stratificazione delle attribuzioni), 

| oppure sul tipo di prodotto derivato (es. per la ODbL le modifiche dei dati sono rilasciabili solo con 
ODbL mentre i prodotti derivati come le mappe con ogni altra licenza) 











La creazione di un'opera derivata sotto la licenza proposta è impossibile 














Figura 6.4 Tabella di compatibilità tra le principali licenze open data, da 
cui emergono i problemi di compatibilità delle licenze con clausola share 
alike. Versione rielaborata da Andrea Mangiatordi del grafico che si trova 
nelle Linee guida nazionali per la valorizzazione del patrimonio informativo 
pubblico (https://docs.italia.it/italia/daf/lg-patrimonio- 


pubblico/it/stabile/licenzecosti.html), a sua volta tratto dalla tabella 


presente nell'articolo di Federico Morando “Interoperabilità giuridica: 
rendere i dati (pubblici) aperti compatibili con imprese e comunità online” 
(JLIS.it, gennaio 2013). L'articolo originario e la versione originale della 
tabella sono disponibili liberamente qui: 
http://leo.cineca.it/index.php/jlis/article/download/5461/7928; e sono 


rilasciati, come anche la versione presentata in questo libro, sotto licenza 
Creative Commons Attribution 4.0 International. 


NOTA 

Per la versione estesa si veda oltre che l’articolo originario anche la 
presentazione a slide dello stesso Morando “Licenze degli open data” 
(Ravenna, 19 ottobre 2015), disponibile su SlidesShare: 


Open science data: gli open 
data della ricerca scientifica 


Una sottocategoria di open data entrati al centro del 
dibattito negli ultimi anni sono gli open data relativi alla 
ricerca scientifica, chiamati più comunemente “open 
science data” o anche “open research data”. 

La diffusione delle tecnologie digitali e l'aumento 
esponenziale della capacità di archiviazione e di 
trasmissione di dati hanno fatto sì che negli ultimi 
decenni i ricercatori non si siano limitati a pubblicare i 
risultati dei loro studi nelle classiche forme testuali (tesi, 
articoli, saggi, monografie, report) o grafiche 
(diagrammi, tabelle, mappe), ma si siano spinti sempre 
più a diffondere anche i dataset su cui si sono fondati gli 
studi e da cui derivano le conclusioni raggiunte. 

Si tratta di un passaggio indubbiamente rivoluzionario 
perché realizza a pieno titolo l’idea galileiana di un 


approccio scientifico basato sulla riproducibilità delle 
prove sperimentali e dei calcoli da parte di altri 
scienziati, i quali possono da un lato confermare o 
confutare i risultati estratti da quei dati, dall'altro 
possono partire dagli stessi dati per arrivare ad altri e 
ulteriori risultati. 

I teorici che si sono occupati di questo tema (e del più 
ampio tema della “open science”) hanno individuato una 
serie di best practice per una virtuosa e innovativa 
condivisione dei dati della ricerca scientifica e hanno 
indicato le caratteristiche essenziali che tali dati devono 
avere: queste caratteristiche possono essere riassunte 
nell’acronimo FAIR, cioè Findable, Accessible, 
Interoperable, Reusable. 


NOTA 

Principalmente si veda l'articolo “The FAIR Guiding Principles for 
scientific data management and stewardship” di Wilkinson, 
Dumontier e Mons uscito su Nature / Scientific Data nel 2016. 


Riportiamo la traduzione italiana del documento “FAIR 


traduzione italiana sono disponibili nei termini della 
licenza Creative Commons Attribution 4.0 International. 





Findable (Reperibili) 

Il primo passo per (ri)utilizzare i dati è trovarli. | metadati e i dati 
dovrebbero essere facili da trovare sia per l'uomo sia per il computer. | 
metadati leggibili meccanicamente sono essenziali per il rilevamento 
automatico di set di dati e servizi, quindi questo è un componente 
essenziale del processo di “FAIRification”, 


e FI1. Ai (meta)dati viene assegnato un identificatore univoco e 
persistente a livello globale. 


e F2.1 dati sono descritti con metadati completi (definiti di seguito 
nel punto R1). 


e F3. I metadati includono in modo chiaro ed esplicito 
l’identificatore dei dati che descrivono. 

e F4. | (meta)dati sono registrati o indicizzati in una risorsa 
ricercabile. 


Accessible (Accessibili) 

Una volta che l'utente trova i dati richiesti, deve sapere come è 
possibile accedervi, possibilmente includendo autenticazione e 
autorizzazione. 


e Al. | (meta)dati sono recuperabili dal loro identificatore usando 
un protocollo di comunicazione standardizzato. 
- A1.1. Il protocollo è aperto, gratuito e universalmente 
implementabile. 
- A1.2. Il protocollo consente una procedura di autenticazione e 
autorizzazione, ove necessario. 
e A2. | metadati sono accessibili, anche quando i dati non sono più 
disponibili. 
Interoperable (Interoperabili) 
I dati di solito devono essere integrati con altri dati. Inoltre, i dati 
devono interagire con applicazioni o flussi di lavoro per analisi, 
archiviazione ed elaborazione. 


e Il. | (meta)dati utilizzano un linguaggio formale, accessibile, 
condiviso e ampiamente applicabile per la rappresentazione della 
conoscenza. 

e 12.1 (meta)dati utilizzano vocabolari che seguono i principi FAIR. 

e 13. | (meta)dati includono riferimenti qualificati ad altri (meta) 
dati. 


Reusable (Riutilizzabili) 

L'obiettivo finale del FAIR è ottimizzare il riutilizzo dei dati. A tale scopo, 
i metadati e i dati devono essere ben descritti in modo da poter essere 
replicati e/o combinati in diverse impostazioni. 


e RI. | (meta)dati sono ampiamente descritti con una pluralità di 
attributi accurati e pertinenti. 
- R1.1. | (meta)dati vengono rilasciati con una licenza di utilizzo 
dei dati chiara e accessibile. 
- R1.2. 1 (meta)dati sono associati a una provenienza dettagliata. 
- R1.3. | (meta)dati soddisfano gli standard della comunità 
rilevanti per lo specifico dominio. 


ie “—_—_————_Ò_Òu_ÒÒ___uoÒ_______uo_u_u_u_Ò_u_omuàm4_Àd_yuy '1_ _o_uat1 

Si noti che, come opportunamente ricorda Elena 
Giglia, “accessibili” non significa “aperti”; affinché i dati 
siano accessibili “è sufficiente sapere come arrivare ai 
dati e come poterli eventualmente scaricare”. Ma 
possono essere previsti sistemi di autenticazione 0 
particolari restrizioni alla diffusione e al riutilizzo sulla 
base di norme che non hanno a che fare con il copyright, 
come per esempio la privacy, la sicurezza, il segreto 
militare. 


NOTA 
Si veda la pagina divulgativa sul concetto di dati FAIR curata dalla 
stessa Giglia per il sito dell'Unità di Progetto Open Access 


dell'Università di Torino (https://ww.oa.unito.it/new/cose-utile/dati- 


Anche se nell’acronimo FAIR non è espressamente 
indicato il requisito dell’openness, l'apertura dei dati, 
per come l'abbiamo intesa in queste pagine, cioè dal 
punto di vista della licenza d'uso, è una componente 
della quarta caratteristica (la riusabilità) come indicato 
al punto R.1.1. 

Quali sono quindi le licenze più appropriate per 
rendere davvero riutilizzabili i dati della ricerca? Per 
rispondere a questa domanda, dobbiamo innanzitutto 
tenere presente che gli open science data rappresentano 
un sottoinsieme degli open data e dunque restano 
comunque escluse tutte le licenze che pongono vincoli 
sulla realizzazione di opere derivate e sullo sfruttamento 
commerciale delle opere. Ciò trova riverbero e conferma 
anche nella Dichiarazione di Berlino sull'accesso aperto 
alla letteratura scientifica, cioè il manifesto principale 


del movimento Open Access sottoscritto e ratificato dai 
rettori dei principali atenei del pianeta. 


NOTA 
Il testo integrale del documento in versione italiana è disponibile 
all’URL https://it.wikisource.org/wiki/Dichiarazione di Berlino. Per 


approfondimenti sul tema si rimanda a Simone Aliprandi, Come 
gestire i diritti d'autore per fare Open Access, capitolo 4 del libro 
“Fare Open Access. La libera diffusione del sapere scientifico nell'era 
digitale”, edito da Ledizioni nel 2017 e liberamente scaricabile al sito 


Secondo il documento “Fact Sheet on Creative 
Commons & Open Science” realizzato dal chapter 
britannico di Creative Commons (disponibile online 
all’URL https://zenodo.org/record/840652#.XxyxlPgzY1I), la soluzione 


migliore per massimizzare il riuso dei dati della ricerca è 
sempre e comunque una dichiarazione di rilascio in 
pubblico dominio (come CCO0). Secondo questo 
documento, dunque, anche una licenza di mera 
attribuzione risulta non ottimale se applicata ai dataset 
della ricerca scientifica (specie se si tratta di dataset 
prodotti da enti di ricerca pubblici o comunque 
nell’ambito di progetti di ricerca finanziati da fondi 
pubblici), perché comunque aggiunge un vincolo 
“contrattuale” rispetto alle modalità di menzione della 
paternità dell’opera e nello stesso tempo potrebbe 
comunicare l’errata percezione che esista sempre un 
diritto esclusivo sui dati, anche in quei casi in cui il 
dataset licenziato è invece per altre ragioni privo di 
qualsivoglia tutela. 
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Figura 6.5 Diagramma concettuale che rappresenta il processo per 
rendere FAIR i dati “oscuri”: ogni curva indica un passo verso l'aumento del 
valore e del potenziale dei dati per la scienza. L'immagine è sotto licenza 
Creative Commons Attribution 4.0 International ed è tratta dall'articolo 
“From the Field to the Cloud: A Review of Three Approaches to Sharing 
Historical Data From Field Stations Using Principles From Data Science” di 
Easterday, Paulson, DasMohapatra, Alagona e altri, pubblicato sulla rivista 
Frontiers in Environmental Science nell'ottobre 2018 (disponibile all’URL 
https://www.frontiersin.org/articles/10.3389/fenvs.2018.00088/full). 


Capitolo 7 


Quando il dato è (anche) 
personale 


Entrano in scena le norme 
sulla privacy 


Quando si parla di “governance dei dati” 
l'immaginario collettivo quasi in automatico e all'istante 
fa un collegamento con il concetto di privacy; come se i 
dati fossero solo personali e non potessero invece 
esistere dati non personali. In realtà, abbiamo sviluppato 
buona parte dei capitoli di questo libro senza fare un 
minimo riferimento al concetto di dato personale e 
utilizzando un’accezione neutra di dato. 

Tutte le considerazioni fatte fin qui valgono per i dati 
tout court; nei prossimi paragrafi capiremo che, quando 
si gestiscono dati personali, entra in gioco un livello di 
norme ulteriori che appunto riguardano la tutela e il 
trattamento di questa particolare tipologia di dati. 

Gli atti normativi in materia di privacy e di 
trattamento dei dati personali sono un fenomeno 
relativamente recente. La prima legge statunitense sulla 
privacy è il Privacy Act del 1974; sul fronte europeo la 
prima direttiva è stata la direttiva n. 95/46/CE relativa 


alla tutela delle persone fisiche con riguardo al 
trattamento dei dati personali, nonché alla libera 
circolazione di tali dati, poi superata e abrogata dal 
Regolamento generale sulla protezione dei dati Reg. n. 
2016/679/UE, anche noto con l'acronimo anglofono 
GDPR (General Data Protection Regulation). Le norme di 
riferimento per questo capitolo saranno quindi tratte 
proprio da questo testo. 

Ciò non toglie che il legislatore europeo si sia 
preoccupato anche di fornire una dettagliata normativa 
sulla gestione e sulla circolazione dei dati non personali; 
lo ha fatto approvando di recente l'apposito 
Regolamento (UE) n. 2018/1807 relativo a un quadro 
applicabile alla libera circolazione dei dati non personali 
nell'Unione Europea. Il testo del regolamento è 


La definizione di dato 
personale fornita dalla legge 


Per capire bene quando nell'attività di gestione dei 
dati debbano essere considerate anche le norme sulla 
tutela dei dati personali, partiamo proprio dalla 
definizione di dato personale, e nello specifico da quella 
contenuta nel GDPR all'articolo 4: 


[per dato personale si intende] qualsiasi informazione riguardante 
una persona fisica identificata o identificabile (“interessato”); si 
considera identificabile la persona fisica che può essere identificata, 
direttamente o indirettamente, con particolare riferimento a un 
identificativo come il nome, un numero di identificazione, dati relativi 


all'ubicazione, un identificativo online o a uno o più elementi 

caratteristici della sua identità fisica, fisiologica, genetica, psichica, 

economica, culturale o sociale. 

Dunque il concetto di dato personale riguarda solo le 
persone fisiche, cioè gli individui, gli esseri umani. Sono 
escluse dal campo d'azione delle norme sulla privacy le 
persone giuridiche, ma rimangono comprese le 
cosiddette “partite IVA” individuali, cioè quei soggetti 
imprenditoriali o professionali che, pur svolgendo 
attività commerciali, lo fanno come persone fisiche. 

Questo è già un importante discrimine; nella gestione 
di un dataset riguardante attività lavorative sarà 
opportuno separare le persone fisiche dalle persone 
giuridiche. 


Il frequente equivoco sul 
concetto di “titolare del 
dato” 


Nell'ambito della governance di dati, si usa spesso 
l’espressione “titolare del dato”, tuttavia questa 
espressione è foriera di numerosi equivoci per il 
semplice fatto che non trova riscontro in nessuna norma 
giuridica vigente. 

È quindi consigliabile non usare mai quell’espressione. 
Quando parliamo di “titolarità” è importante distinguere 
il piano privacy e il piano proprietà intellettuale. 

Se siamo sul piano privacy l’espressione più corretta è 
“titolare del trattamento”. Riportando la definizione 
fornita dal GDPR, sempre all'articolo 4: 


[per titolare del trattamento si intende] la persona fisica o giuridica, 

l'autorità pubblica, il servizio o altro organismo che, singolarmente o 

insieme ad altri, determina le finalità e i mezzi del trattamento di dati 

personali. 

Secondo alcuni commentatori, il legislatore italiano, in 
occasione della traduzione e del recepimento del GDPR 
avvenuti tra gli anni 2016 e 2018, avrebbe potuto in 
modo più opportuno utilizzare un'espressione meno 
ambigua che si avvicinasse dal punto di vista semantico 
alla versione inglese del GDPR, in cui si trova “data 
controller” (letteralmente “colui che ha il controllo dei 
dati”). 

Il titolare del trattamento è dunque colui che tratta i 
dati senza ricevere istruzioni da altri, colui che decide 
“perché” e “come” devono essere trattati i dati. Non è 
tanto chi gestisce concretamente i dati, quanto chi 
decide il motivo e le modalità del trattamento. 

Non bisogna poi confondere il titolare del trattamento 
con il responsabile del trattamento; figura distinta che 
viene definita dal GDPR come il soggetto che tratta dati 
personali per conto del titolare del trattamento (nella 
versione inglese “data processor”, cioè letteralmente 
“colui che elabora i dati”). 

Molti però parlano di “titolare del dato” per indicare la 
persona fisica cui i dati sono riconducibili e che 
attraverso essi può essere identificata o identificabile; 
l'essere umano la cui riservatezza è tutelata e che può 
esercitare i diritti di accesso ai dati, di rettifica o di 
cancellazione degli stessi. Anche questo utilizzo è 
improprio, perché più precisamente tutta la normativa in 
materia di privacy (il GDPR, come anche il precedente 


Codice Privacy del 2003) parla non di “titolare del dato” 
ma di “interessato” (dizione inglese: “data subject”). 

Fin qui il piano privacy, che già comporta non poche 
complicazioni terminologiche. Se invece passiamo al 
piano proprietà intellettuale è più corretto parlare di 
titolare dei diritti sulla banca dati; e più nello specifico si 
può parlare di “autore della banca dati” in caso di banca 
dati con carattere creativo, oppure di “costitutore di 
banca dati” in caso di banca dati senza carattere 
creativo. Come abbiamo già spiegato, infatti, non c'è 
alcuna “titolarità”, nessuna “proprietà”, sul singolo dato 
“crudo” ma possono esistere dei diritti di privativa solo 
su un insieme organizzato di dati, appunto la banca dati. 


Il concetto di trattamento e 
le sue basi giuridiche 


L'altro concetto che è fondamentale mettere bene a 
fuoco per orientarsi è quello di “trattamento di dati 
personali”. Anche qui è opportuno riportare la 
definizione del GDPR, sempre contenuta nell'articolo 4: 


[per trattamento si intende] qualsiasi operazione o insieme di 
operazioni, compiute con o senza l'ausilio di processi automatizzati e 
applicate a dati personali o insiemi di dati personali, come la raccolta, 
la registrazione, l’organizzazione, la strutturazione, la conservazione, 
l'adattamento o la modifica, l'estrazione, la consultazione, l’uso, la 
comunicazione mediante trasmissione, diffusione o qualsiasi altra 
forma di messa a disposizione, il raffronto o l’'interconnessione, la 
limitazione, la cancellazione o la distruzione. 


Da una lettura della norma, anche senza avere 


particolare confidenza con la materia, si deduce che in 
sostanza qualsiasi attività svolta con dati personali 


integra un trattamento e quindi innesca gli oneri previsti 
dalla normativa sulla privacy. Dunque, colui che 
abbiamo chiamato “costitutore di banca dati”, nel 
momento in cui nella sua banca dati raccoglie e 
organizza anche dati personali, assume il ruolo di 
titolare del trattamento dal punto di vista della 
normativa sulla privacy. 

Secondo il GDPR il trattamento di tali dati può essere 
effettuato solo se sussiste la cosiddetta “base giuridica”, 
cioè una condizione che rende lecito il trattamento ed 
esime il titolare del trattamento da sanzioni. 

I fondamenti di liceità del trattamento indicati 
dall'articolo 6 GDPR sono in totale sei: 

a) l'interessato ha espresso il consenso al trattamento dei propri dati 


personali per una o più specifiche finalità; 


b) il trattamento è necessario all'esecuzione di un contratto di cui 
l'interessato è parte o all'esecuzione di misure precontrattuali 
adottate su richiesta dello stesso; 


c) il trattamento è necessario per adempiere un obbligo legale al 
quale è soggetto il titolare del trattamento; 


d) il trattamento è necessario per la salvaguardia degli interessi vitali 
dell'interessato o di un’altra persona fisica; 


e) il trattamento è necessario per l'esecuzione di un compito di 
interesse pubblico o connesso all'esercizio di pubblici poteri di cui è 
investito il titolare del trattamento; 


f) il trattamento è necessario per il perseguimento del legittimo 
interesse del titolare del trattamento o di terzi, a condizione che non 
prevalgano gli interessi o i diritti e le libertà fondamentali 
dell'interessato che richiedono la protezione dei dati personali, in 
particolare se l'interessato è un minore. 


Vi sono quindi situazioni in cui la base giuridica è il 
consenso dell'interessato; in tal caso è importante tener 
presente che il consenso dev'essere libero, esplicito, 
informato, dimostrabile (se possibile per iscritto) e 
rimane comunque revocabile su richiesta 
dell'interessato. 


NOTA 

II Considerando 32 del GDPR precisa che “il consenso dovrebbe 

essere prestato mediante un atto positivo inequivocabile con il quale 

l'interessato manifesta l'intenzione libera, specifica, informata e 

inequivocabile di accettare il trattamento dei dati personali che lo 

riguardano, ad esempio mediante dichiarazione scritta, anche 
attraverso mezzi elettronici, o orale”. 

Vi sono poi situazioni, del tutto equiordinate rispetto 
alla prima, in cui la base giuridica è invece l'esecuzione 
di un contratto e altre in cui è una specifica mission 
amministrativa. Ulteriori e più stringenti condizioni sono 
poi previste per il trattamento dei dati appartenenti a 
particolari categorie, tra i quali per esempio i dati 
relativi alla salute, quelli genetici e biometrici o idonei a 
rivelare l'origine etnica 0, ancora, le convinzioni 
religiose. Si tratta dei dati che il precedente testo del 
Codice Privacy chiamava “dati sensibili”; un termine che 
troppo spesso viene utilizzato in modo improprio come 
sinonimo generico di “dati personali”. 


L’'equivoco tra dato pubblico 
e dato liberamente 
utilizzabile 


Un altro equivoco molto diffuso quanto pericoloso è 
quello di pensare che un dato che sia stato reso pubblico 
sia anche liberamente utilizzabile da chiunque. 

Il fatto che un dato sia stato reso pubblico e sia 
liberamente accessibile da parte di tutti non equivale 
affatto a una liberatoria generalizzata e illimitata al suo 
utilizzo da parte di chiunque e per qualsivoglia finalità. 

Un esempio abbastanza classico sono gli indirizzi PEC 
(posta elettronica certificata) dei professionisti iscritti 
agli albi professionali. Per esigenze di pubblicità e di 
trasparenza, gli ordini professionali sono tenuti per 
legge a esporre un elenco aggiornato degli indirizzi PEC 
dei professionisti, che tra l’altro vengono associati ad 
altri dati personali come per esempio al codice fiscale e 
in alcuni casi alla data di nascita. 

Come detto, i professionisti sono persone fisiche, 
dunque, anche se agiscono come soggetti professionali 
dotati di partita IVA e anche se alcuni dei loro dati sono 
resi liberamente accessibili attraverso pubblici registri, 
sono comunque coperti dalla normativa sulla privacy. 
Non è quindi lecito prelevare i dati da tali elenchi 
pubblici e poi utilizzarli per inviare ai professionisti 
proposte commerciali; ma è necessario che vi sia un 
esplicito consenso da parte degli interessati. 

Lo stesso si applica a qualsiasi altro dato personale 
che venga pubblicato da enti pubblici in ossequio alle 
norme sulla trasparenza della pubblica amministrazione: 
dai partecipanti a concorsi o gare, ai soggetti beneficiari 
di agevolazioni fiscali o concessioni pubbliche. 


Non a caso nell'ultima versione dell'articolo 52 del 
Codice dell’amministrazione digitale (norma che ha 
introdotto il cosiddetto principio “open by default” per 
abilitare il riutilizzo dei dati pubblicati dalle pubbliche 
amministrazioni) il legislatore ha espressamente 
precisato che comunque i dati personali restano esclusi 
dall'ambito di azione della norma. 


I dati “indirettamente 
personali” 


A complicare non poco la questione è l’avverbio 
“indirettamente” che compare nella definizione di dato 
personale (sia in quella riportata qui sopra tratta 
dall'articolo 4 del GDPR, sia in quella della direttiva 
privacy del 1995, sia nel nostro Codice Privacy del 
2003); una parola che da sola riesce a stendere un velo 
di foschia sulla definizione, la rende molto ampia ed 
elastica e obbliga l'interprete a interrogarsi di volta in 
volta se i dati che sta trattando siano riconducibili anche 
solo in modo indiretto a una persona fisica. 

Ci sono infatti molti casi in cui il dato, preso 
singolarmente, fuori dal suo contesto e osservato 
superficialmente, appare privo di collegamenti con una 
persona fisica; ma, nel momento in cui lo contestualizzo 
e lo metto in relazione ad altri dati presenti nello stesso 
dataset o in altre fonti, lo stesso dato diventa personale 
e quindi sottoposto a tutte le cautele previste dalla 
normativa privacy. 


Il Considerando 26 del GDPR approfondisce così il 
tema dell’identificabilità anche indiretta di una persona: 


I dati personali sottoposti a pseudonimizzazione, i quali potrebbero 
essere attribuiti a una persona fisica mediante l'utilizzo di ulteriori 
informazioni, dovrebbero essere considerati informazioni su una 
persona fisica identificabile. Per stabilire l’identificabilità di una 
persona è opportuno considerare tutti i mezzi, come l'individuazione, 
di cui il titolare del trattamento o un terzo può ragionevolmente 
avvalersi per identificare detta persona fisica direttamente o 
indirettamente. Per accertare la ragionevole probabilità di utilizzo dei 
mezzi per identificare la persona fisica, si dovrebbe prendere in 
considerazione l'insieme dei fattori obiettivi, tra cui i costi e il tempo 
necessario per l’identificazione, tenendo conto sia delle tecnologie 
disponibili al momento del trattamento, sia degli sviluppi tecnologici. 
Come si può notare, si tratta di valutazioni molto 
delicate, che richiedono un certo occhio clinico e devono 
perciò essere effettuate da professionisti specializzati e 
con esperienza. 
Facciamo qualche esempio concreto di dati in 
apparenza non personali che tuttavia, ad alcune 
condizioni, possono essere considerati “indirettamente 


personali”. 


I dati territoriali a fini statistici 

Nella raccolta di dati territoriali di qualsiasi tipo su 
un’area abitata vi è sempre il rischio che l'informazione 
fornita possa essere ricondotta a un gruppo di persone o 
addirittura a una persona specifica. Ciò dipende molto 
dal livello di precisione e - potremmo dire - di 
“risoluzione” del dato; più il dato raccolto ha riferimenti 
geografici precisi, più c'è il rischio che esso violi la 
privacy. 


Ipotizziamo di essere un’azienda che realizza 
statistiche territoriali e che attraverso l’analisi delle 
acque fognarie vuole individuare in quale percentuale 
gli abitanti di una determinata zona fanno uso di 
psicofarmaci. Analizziamo le acque dei capoluoghi della 
Lombardia facendo prelievi nei depuratori comunali, 
mettiamo i risultati in rapporto con la densità di 
popolazione e arriviamo a dire che gli abitanti di Milano, 
Brescia e Mantova ne fanno un uso molto elevato, 
mentre gli abitanti di Sondrio, Pavia e Lecco ne fanno 
invece un uso poco elevato. Un'esposizione del dato di 
questo tipo non sembra in alcun modo poter avere rilievi 
di privacy. Ora ipotizziamo invece di fare la stessa cosa 
ma facendo prelievi non nei depuratori bensì in modo 
capillare nei principali snodi della rete fognaria. Anche 
in questo caso non dovremmo incorrere in problemi di 
violazione della riservatezza delle persone, anche in 
virtù dell'alta densità di popolazione dei capoluoghi 
lombardi. Se anche diciamo che in viale Sarca a Milano 
si è rilevata la più alta concentrazione di psicofarmaci 
rispetto a tutta la città, è difficile che qualche abitante 
di viale Sarca (via piena di palazzi a sette piani e 
densamente popolata) possa lamentare una violazione 
della sua privacy. 

Ipotizziamo infine di fare la stessa identica cosa in 
un’area popolata così poco densamente che, 
quand’anche i rilievi venissero fatti nei principali snodi, 
sarebbe molto facile riuscire a capire da quali abitazioni 
provengono quelle acque reflue. Ci sono zone 
dell'Australia (ma anche alcune zone rurali e montane 


italiane) in cui vi sono abitazioni private che stanno a 
qualche chilometro di distanza l'una dall'altra. Fornire 
un dato sull'utilizzo di psicofarmaci in una zona simile ci 
obbliga ad “abbassare la risoluzione” del dato stesso e a 
fornirlo in maniera sufficientemente aggregata da non 
poter essere riconducibile a una singola abitazione e 
nemmeno a un numero molto ristretto di abitazioni. 


I dati meteorologici 

Dati come la pressione atmosferica, il tasso di umidità, 
la temperatura esterna hanno davvero molto poco di 
“personale”. Tuttavia esistono progetti web che 
permettono di raccogliere e monitorare questi dati 
attraverso delle centraline a basso costo acquistabili da 
utenti privati. Succede quindi che un privato cittadino 
acquista una di queste centraline, la mette sul balcone o 
sul tetto della sua abitazione, la connette alla rete 
Internet e permette alla centralina di caricare 
periodicamente i dati su una piattaforma web. Quasi 
tutte queste centraline hanno un rilevatore GPS e 
dunque, tra i vari dati che possono raccogliere e 
comunicare al server, vi è anche la geolocalizzazione, 
che in questo caso corrisponde alla posizione geografica 
precisa dell'abitazione privata di una persona fisica. A 
ciò aggiungiamo che per caricare i dati il proprietario 
della centralina deve creare un suo account nella 
piattaforma web. 


I dati sui rifugi di montagna 


Ipotizziamo di essere una startup che vuole realizzare 
un sito web che permetta agli escursionisti di mettersi in 
contatto con più facilità con i rifugi di montagna. La 
tentazione che potrebbe venire è quella di utilizzare gli 
elenchi pubblici che le regioni e le comunità montane 
compilano ed espongono con i recapiti dei rifugi di 
montagna ed estrarre i dati da lì. 

Entriamo qui nel campo del problema già segnalato 
della distinzione tra persone giuridiche (non rilevanti 
per la privacy) e persone fisiche (rilevanti per la 
privacy). Infatti una buona fetta dei rifugi è gestita da 
persone fisiche, a volte nemmeno dotate di una partita 
IVA, per le quali il rifugio rappresenta anche la propria 
residenza privata. Benché negli elenchi pubblici non vi 
sia questa distinzione (perché, ai fini della compilazione 
dell'elenco pubblico, le regioni e le comunità montane 
non sono interessate alla distinzione), se siamo una 
startup che invece fa quest'attività a scopo di lucro 
(legittimamente) dobbiamo preoccuparci di fare una 
distinzione a posteriori dei casi in cui il rifugio è gestito 
da una persona giuridica e dei casi in cui invece è 
gestito da una persona fisica. Noi per le persone fisiche 
dovremo attivarci per ottenere il consenso al 
trattamento del dato, essendo il consenso l’unica base 
giuridica utilizzabile in questo caso; mentre, al contrario, 
le regioni e le comunità montane possono sfruttare 
un'altra base giuridica legata alla funzione pubblico- 
istituzionale di quegli elenchi. 


Anonimizzazione e 
pseudonimizzazione 


Nonostante il GDPR all'articolo 4 fornisca una serie 
molto completa e dettagliata di definizioni necessarie a 
comprendere e applicare le norme successive, non si 
trova una definizione di “dato anonimo” o di 
“anonimizzazione”. 

Possiamo però dedurre qualche utile chiarimento dalla 
lettura del Considerando 26, nel quale si fa presente che 
“i principi di protezione dei dati non dovrebbero 
applicarsi a informazioni anonime, vale a dire 
informazioni che non si riferiscono a una persona fisica 
identificata o identificabile o a dati personali resi 
sufficientemente anonimi da impedire o da non 
consentire più l’identificazione dell'interessato. Il 
presente regolamento non si applica pertanto al 
trattamento di tali informazioni anonime, anche per 
finalità statistiche o di ricerca”. 

In altre parole, la normativa sulla privacy non si 
occupa di dati anonimi per il semplice fatto che essi non 
sono dati personali, in quanto non sono in alcun modo 
riconducibili a una persona fisica nemmeno 
indirettamente. 

L'anonimizzazione è quindi un processo di totale e 
irreversibile neutralizzazione del dato, di cancellazione 
di qualsivoglia elemento del dato che possa in qualche 
modo renderlo riconducibile a una persona. 

In compenso, l'articolo 4 GDPR ci fornisce una 
definizione ben chiara di un altro concetto parallelo ma 


in sostanza diverso: il concetto di pseudonimizzazione. 


[per pseudonimizzazione si intende] il trattamento dei dati personali 

in modo tale che i dati personali non possano più essere attribuiti a 

un interessato specifico senza l'utilizzo di informazioni aggiuntive, a 

condizione che tali informazioni aggiuntive siano conservate 

separatamente e soggette a misure tecniche e organizzative intese a 

garantire che tali dati personali non siano attribuiti a una persona 

fisica identificata o identificabile. 

A differenza di un dato anonimo, un dato 
pseudonimizzato può essere ricostruito a posteriori e 
portare comunque a un’identificazione indiretta 
dell'interessato. 

A complemento della definizione riportata, il 
Considerando 75, parlando dei rischi per i diritti e le 
libertà delle persone fisiche legati al trattamento dei 
dati personali, menziona la fattispecie della “decifratura 


non autorizzata della pseudonimizzazione”. 


Il caso delicato delle 
sentenze 


Un esempio che di solito emerge in tema di 
anonimizzazione e pseudonimizzazione è quello delle 
sentenze e in generale dei provvedimenti giudiziari 
(ordinanze, decreti, verbali, determine). Come è noto, le 
sentenze di tribunali e corti vengono emesse “in nome 
del popolo italiano” e sono senza dubbio un atto 
pubblico. Una sentenza, nonostante sia a tutti gli effetti 
un'opera dell'ingegno che richiede un tangibile sforzo 
intellettuale per la sua stesura, risulta fuori dal campo 
d'azione del diritto d'autore in virtù dell'articolo 5 LDA e 


dunque è un documento in pubblico dominio e 
liberamente utilizzabile da chiunque senza vincoli di 
copyright. 

NOTA 

L'articolo 5 recita: “Le disposizioni di questa legge non si applicano ai 

testi degli atti ufficiali dello stato e delle amministrazioni pubbliche, 

sia italiane che straniere”, 

Tuttavia, anche se il diritto d'autore si fa da parte, non 
viene meno il diritto della privacy che agisce sui (molti) 
dati personali che una sentenza di norma riporta; 
d'altronde la sentenza è sì un atto pubblico, ma è 
comunque un atto che tratta vicende private 
riconducibili a persone fisiche. E attenzione: non si 
tratta solo dei classici dati anagrafici che compaiono 
nell’incipit della sentenza; ma anche delle vicende e dei 
fatti narrati all’interno del documento, che spesso non 
riguardano solo le parti in causa bensì anche soggetti 
esterni alla vicenda (come i testimoni o membri nel 
nucleo famigliare che vengono menzionati nella 
ricostruzione delle dinamiche processuali). 

La soluzione più veloce e radicale è quella della totale 
anonimizzazione dei provvedimenti giudiziari, effettuata 
attraverso la cancellazione di tutti i dati personali in essi 
contenuti e anche dei riferimenti che potrebbero 
comunque portare a una ricostruzione e a 
un’identificazione a posteriori: pensiamo per esempio al 
numero di ruolo del provvedimento che, con una ricerca 
in specifiche banche dati, permette di risalire alle parti 
coinvolte nel procedimento. Tuttavia, 
un’anonimizzazione totale produce spesso l’effetto 
collaterale di rendere illeggibile e incomprensibile il 


provvedimento; perciò chi vuole mettere a disposizione 
servizi di informazione giuridica o banche dati di 
sentenze deve piuttosto optare per la soluzione della 
pseudonimizzazione e in particolare di una 
pseudonimizzazione mirata e concepita appositamente 
per quel particolare tipo di documenti. 

Il problema della pubblicità dei provvedimenti 
giudiziari e della tutela dei dati personali in essi riportati 
è emerso proprio negli ultimi anni quando le stesse corti 
si sono attivate per rendere liberamente accessibili 
online le loro banche dati. Emblematico e anche molto 
discusso è stato il caso della Corte di Cassazione che nel 
2014 decise di pubblicare liberamente sul suo sito web 
decine di migliaia di sentenze 
(http://mw.italgiure.giustizia.it/sncass/), rendendole non 


indicizzabili dai motori di ricerca ma lasciando tutti i dati 
personali in chiaro, compresi dati riconducibili a 
situazioni molto delicate (questioni legate a malattie 
gravi e contagiose, vittime di reati a sfondo sessuale, 
situazioni di divorzio e affidamento minori). Le critiche 
pervenute, tra cui una preoccupata lettera aperta del 
Garante Privacy, portarono la Corte di Cassazione a 
rimuovere alcuni dei provvedimenti; anche se nel 
complesso non ci fu affatto una “marcia indietro” e anzi 
il Primo Presidente della Corte Suprema rivendicò di aver 
agito in virtù di un legittimo interesse da parte della 
corte di esporre tali documenti sul suo sito istituzionale. 


NOTA 
“Pubblicazione integrale sul Web delle sentenze pronunciate dalla 
Corte di Cassazione e protezione dei dati personali”, lettera di 


Antonello Soro, Presidente del Garante per la protezione dei dati 


personali, a Giorgio Santacroce, Primo Presidente della Corte 
Suprema di Cassazione: 
https://ww.garanteprivacy.it/home/docweb/-/docweb-display/docweb/3432529, 


La pubblicazione dei provvedimenti è infatti 
proseguita (pur con maggiore attenzione sul piano dei 
dati personali) con un ritmo di più di ottantamila 
provvedimenti all'anno. E lo stesso esempio è stato 
seguito anche dal Consiglio di Stato, dalla Corte dei 
Conti, dai Tribunali Amministrativi Regionali e anche da 
alcune Corti d'Appello. 

Non ultimo, bisogna considerare l'aspetto del diritto 
all'oblio. La messa a disposizione sul Web dei 
provvedimenti giudiziari, benché resi non indicizzabili 
per i motori di ricerca, pone non irrilevanti questioni di 
diritto all'oblio; con essa infatti vicende giudiziarie 
risalenti a molti anni fa possono essere comunque 
sempre rilette e riportate a “nuova vita” da qualsiasi 
utente di Internet, anche senza necessità di qualificarsi 
come operatore del settore giustizia o come 
professionista dell’informazione che esercita il suo 
diritto di cronaca. 


L'immagine di una persona 
come dato personale 


L'immagine di una persona è soggetta a una tutela 
multipla da parte dell'ordinamento giuridico. Secondo il 
diritto della proprietà intellettuale i cosiddetti diritti 
d'immagine (denominati in modo più corretto “diritti 
relativi al ritratto”) sono tutelati con un diritto esclusivo 
in capo alla persona fisica che presta la sua immagine 


affinché sia ritratta e riprodotta anche a scopi 
commerciali (il caso delle fotomodelle e dei testimonial 
della pubblicità). Quando però l’immagine non riguarda 
un personaggio famoso che volontariamente o 
comunque in virtù della sua notorietà espone la sua 
immagine al pubblico, l’immagine deve essere trattata 
anche come dato personale e dunque è necessario 
applicare le cautele previste dalle norme sulla privacy. In 
effetti, la definizione di dato personale fornita 
dall'articolo 4 del GDPR che abbiamo già riportato poco 
sopra menziona espressamente “gli elementi 
caratteristici della [...] identità fisica, fisiologica, 
genetica, psichica, economica, culturale o sociale [di 
una persona]” e una fotografia può rientrare nella 
categoria dei cosiddetti dati biometrici. 

Da una fotografia, oltre ai tratti somatici in sé, si 
possono dedurre tutta una serie di informazioni relative 
alla persona, come per esempio la sua etnia (si pensi al 
colore della pelle), oppure la sua religione (si pensi a 
persone che vengono ritratte con addosso simboli 
religiosi di vario tipo come anche particolari copricapi, 
abiti, accessori), oppure ancora il suo stato di salute (Si 
pensi a persone che riportano mutilazioni, menomazioni, 
cicatrici, segni evidenti di interventi chirurgici). 

In tal senso si è anche espressa la Corte di Cassazione 
con la sentenza numero 17440 del 2 settembre 2015, in 
cui si legge: 


l'immagine di una persona costituisce dato personale [...], 
trattandosi di dato immediatamente idoneo a identificare una 
persona a prescindere dalla sua notorietà, sicché l'installazione di un 
impianto di videosorveglianza all’interno di un esercizio commerciale, 


allo scopo di controllare l’accesso degli avventori, costituisce 

trattamento di dati personali e deve formare oggetto dell'informativa 

[...] rivolta ai soggetti che facciano ingresso nel locale. 

A ciò si aggiunge però l'importante precisazione che si 
trova nel Considerando 51 del GDPR: 


Il trattamento di fotografie non dovrebbe costituire sistematicamente 
un trattamento di categorie particolari di dati personali, poiché esse 
rientrano nella definizione di dati biometrici soltanto quando saranno 
trattate attraverso un dispositivo tecnico specifico che consente 
l’identificazione univoca o l'autenticazione di una persona fisica. 
Anche in questo caso, come in altri che abbiamo 
mostrato, è suggerita la valutazione di un esperto che 
determini di volta in volta quando l’immagine possa 
rivelare dati personali e quindi sia necessario ricercare 
una base giuridica per il suo trattamento o addirittura 


procedere alla sua anonimizzazione. 


Internet come grande oceano 
di dati in cui pescare? 


Senza dubbio la disponibilità massiva di dati via 
Internet apre una nuova era dell’informazione ispirata 
proprio alla raccolta, scambio, rielaborazione di grandi 
masse di dati dalle quali è possibile estrarre un valore 
economico non indifferente: sono i cosiddetti Big Data, 
appunto definiti da alcuni come il nuovo petrolio dell’era 
dell’informazione che stiamo vivendo. La disponibilità di 
tecnologie sempre più performanti e a basso costo per 
l'estrazione e la rielaborazione di dati da Internet 
(software di scraping e parsing) nonché la disponibilità 
di competenze per utilizzarle permette a molti soggetti 


di spingere la raccolta e il riutilizzo di dati verso nuove 
frontiere. 

Tuttavia, se da un lato può esserci la tentazione di 
vedere Internet come un grande oceano di dati da cui 
pescare liberamente, dall'altro lato dobbiamo appunto 
ricordarci che è necessario conoscere e rispettare i limiti 
imposti dalla proprietà intellettuale e dalla data 
protection. Proprio a proposito del concetto di Big Data, 
Fernanda Faini rileva che: 


i dati provengono da fonti diverse e sono di tipologia eterogenea: nei 
big data convergono dati non personali, ma anche dati personali [...]. 
Trattandosi di dati, anche nel caso dei big data come per gli open 
data, i profili maggiormente problematici si individuano proprio nella 
relazione con la normativa in materia di protezione dei dati personali. 
[...] In specifico, a causa delle esaminate caratteristiche che 
connotano il fenomeno, relative in particolare al volume e alla varietà 
delle fonti, l'utilizzo dei big data, laddove siano presenti dati 
personali, rende particolarmente problematico il rispetto dei principi 
di limitazione della finalità [del trattamento], minimizzazione dei dati 
ed esattezza, previsti dalla normativa (Fernanda Faini, Data society. 
Governo dei dati e tutela dei diritti nell'era digitale, Giuffrè, Milano, 
2019, pp. 191-192). 


In altre parole i Big Data rispondono all’esigenza, 0 
potremmo dire alla seducente tentazione, di raccogliere 
attraverso la Rete e attraverso le app per dispositivi 
mobili grandi masse di dati, su cui però solo ex post si 
metteranno le mani per estrarne valore e informazione, 
creando così un cortocircuito con il principio di cui 
all'articolo 5 GDPR secondo cui le finalità di una raccolta 
di dati personali devono essere chiare e definite ex ante 
e con il principio secondo cui i dati raccolti devono 
essere adeguati, pertinenti e limitati a quanto 
necessario rispetto a tali finalità. 


Infine è importante tener presente che, oltre ai vincoli 
derivanti dalle norme sulla proprietà intellettuale e sulla 
privacy, sussiste un ulteriore livello di regole da 
rispettare: le regole di natura contrattuale stabilite dai 
termini d’uso delle varie piattaforme web. 

Anche se buona parte degli utenti li ignora, leggendo i 
termini d’uso dei vari servizi web scopriremmo che quasi 
tutti vietano di fare attività di scraping automatizzato 
dei dati e che, nel caso ciò si verificasse, l'utente 
verrebbe “sanzionato” con la sospensione o con la 
chiusura definitiva dell'account. Si tratta quindi di una 
previsione contrattuale che va ad aggiungersi alle 
sanzioni in genere previste dalla legge per la violazione 
del copyright e delle norme sulla data protection; 
rimane poi salva la possibilità di agire civilmente per il 
risarcimento degli eventuali danni civili derivanti dallo 
scraping non autorizzato. 
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